X470 and IOMMU Groups...

[3mp...@gmail.com]

Hi everyone,

actually I'm a happy Qubes 3.2 user on Intel platform for more than a year now !

I'm looking to upgrade my actual Skylake build with an AMD one with the new Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the same occasion. The Asrock X470 Taichi seems a really nice motherboard for it.

I've found the IOMMU Groups of this motherboard on reddit : https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_taichi_x470/

and it seems there's a big group 13 with LAN, USB and SATA controllers. I wonder if the netVM and USB VM will actually be able to passthrough these controllers if they are in the same IOMMU Group ?

Any Ryzen / Qubes users can confirm this works OK or this is a no go ?

Thanks for your help !

[Tai...@gmx.com]

I would instead consider the purchase of an owner controlled KCMA-D8 or
KGPE-D16 motherboard which you can install libre board+bmc firmware on.

They support qubes 4.0 very well and all devices have their own IOMMU group.

They are a much better choice than a proprietary firmware PSP laden
non-owner controlled new intel/amd system and are the last and best
owner controlled x86 motherboards...now the only new performance CPU
arch that is owner controlled is POWER such as the TALOS 2 system which
currently doesn't have a xen port although it supports other virts such
as KVM/QEMU.

[awokd]

No experience with that exact configuration. You can often passthrough
devices individually even if they are in the same IOMMU group (older
versions of Xen had trouble). Suggest buying from some place with a good
return policy.

[Sphere]

I've observed that Qubes installation rarely ever succeeds on X370 motherboards so I believe the same case applies to X470 motherboards with a higher chance of failure since it is newer. The reason for this I believe is because these high-end gaming motherboards have alot of functionalities/bugs that break/interfere with Qubes installation which is an awful letdown.

So while that mobo having separate IOMMU groups being a plus, it doesn't matter much when you're still in the installation phase of Qubes (Which is the real hard phase to overcome when it comes to Qubes).

[Sphere]

On Thursday, August 9, 2018 at 1:30:49 AM UTC+8, 3mp...@gmail.com wrote:

On a side note, I wanna ask
Do you play games/tried playing games on that Qubes 3.2 installation of yours by any chance?

[Tai...@gmx.com]

On 08/12/2018 03:36 PM, 'awokd' via qubes-users wrote:
>
> No experience with that exact configuration. You can often passthrough
> devices individually even if they are in the same IOMMU group (older
> versions of Xen had trouble).

This is a bad recommendation security wise and I expect better from you.

:<

[awokd]

Hi, Taiidan! The OP seemed to recognize it was ideal to have devices in
separate IOMMU groups, so I assumed he was familiar with the warnings in
https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues and
just wondering if it was technically possible.

[Jean-Philippe Ouellet]

Not sure if also applicable to the X470, but I tried and was
unsuccessful at installing R4 on an Asrock X399 Taichi. I don't
remember all the details, but I think the installer got stuck in a
boot loop, never getting to GUI. YMMV.

[Sphere]

Surely you have checked that your boot sequence really starts at the HDD where you installed qubes right? I got a case where my bios completely could not recognize the drive where I installed my Qubes as bootable and had to do sum stuff in the Boot sector to make it work. The same may apply to you so yeah.

[Marcus Linsner]

>
> I've observed that Qubes installation rarely ever succeeds on X370 motherboards so I believe the same case applies to X470 motherboards with a higher chance of failure since it is newer. The reason for this I believe is because these high-end gaming motherboards have alot of functionalities/bugs that break/interfere with Qubes installation which is an awful letdown.

I've had no issues installing Qubes R4.0 several times(for fun) on Asus PRIME X370-A motherboard.

As an aside, this motherboard even has a setting to use Z370's Trusted Platform Module (TPM) [1] - BIOS setting "Firmware-based Trusted Platform Module (fTPM)", so I assume that I can set up Anti Evil Maid in Qubes but haven't tried yet.

[1] shown as Intel® Platform Trust Technology (Intel® PTT) [2] in this link: https://www.intel.com/content/www/us/en/products/chipsets/desktop-chipsets/z370.html
[2] PTT to TPM mapped in this link: https://www.intel.com/content/www/us/en/support/articles/000007452/mini-pcs.html

[Marcus Linsner]

On Thursday, August 16, 2018 at 1:47:15 PM UTC+2, Marcus Linsner wrote:
> >
> > I've observed that Qubes installation rarely ever succeeds on X370 motherboards so I believe the same case applies to X470 motherboards with a higher chance of failure since it is newer. The reason for this I believe is because these high-end gaming motherboards have alot of functionalities/bugs that break/interfere with Qubes installation which is an awful letdown.
>
> I've had no issues installing Qubes R4.0 several times(for fun) on Asus PRIME X370-A motherboard.

My bad: I just realized you were talking about X370 not Z370, and I've typoed Z370-A above

[FaB]

>>Hi, Taiidan! The OP seemed to recognize it was ideal to have devices in

>>separate IOMMU groups, so I assumed he was familiar with the warnings in
>>https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues and
>>just wondering if it was technically possible.

I am fully aware of the security problematics of PCI passthrough, but until there is a secure solution to passthrough GFX to a VM (Qubes 4.1 I hope !) I am going to continue this way and accept the security decline.

Qubes 4.0 installs great on X470 Taichi Ultimate (Compatibility Support Module mode, didn't try true UEFI) and R7 2700 ! GFX passthrough of AMD 5850 in Windows 10 Guest on xl instructions works too. I continue the testing before posting a complete HCL of the platform. Some error messages to sort out.

Thanks for the help :)

 

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/chNyDUt5suI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/931176ba-4506-4f88-b5b6-5470069d4d94%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tai...@gmx.com]

fTPM is an ME application - it is fake security and usually won't work
with anything that wants a real TPM.

I of course always recommend purchasing a device with no black box
supervisor processors like ME/PSP.

[Tai...@gmx.com]

On 08/16/2018 10:18 AM, FaB wrote:
>>
>>>> Hi, Taiidan! The OP seemed to recognize it was ideal to have devices in
>>
>>> separate IOMMU groups, so I assumed he was familiar with the warnings in
>>> https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues and
>>> just wondering if it was technically possible.
>
> I am fully aware of the security problematics of PCI passthrough, but until
> there is a secure solution to passthrough GFX to a VM (Qubes 4.1 I hope !)
> I am going to continue this way and accept the security decline.

There won't really be.

The issue mainly comes from:

* Hostile firmware re-writes.
* Lack of FLR on most graphics devices.
* The additional complexity of IOMMU-GFX assignment vs regular IOMMU
assigned devices like a network device or HBA.

It isn't that bad if you only assign a single card to a single VM and if
you need it you need it.

Practical reality is that short of being assange or some other very high
profile person no one is going to waste such a high tech exploit on you
when there are much easier ways to go about things.