AMD Iommu compat

[Mihail Ivanov]

I do know for a fact that Xen runs fine on AMD with IOMMU and PCI passthrough works as well. The thing is I am not sure how is Qubes configured? Does it make any assumptions that Vt-d is used instead of IOMMU or does it use any intel specific instructions? As of my understanding currently Qubes is Linux(another OS could be used) on Dom0 with Xen and PV Fedoras(or other) in AppVM's. Correct me if I am mistaken but to me it seems it should run fine on AMD? Still there's only one report of a system that should have working IOMMU in the HCL, yet it's marked as NO.

[Joanna Rutkowska]

On 05/30/14 13:38, Mihail Ivanov wrote:
> I do know for a fact that Xen runs fine on AMD with IOMMU and PCI
> passthrough works as well. The thing is I am not sure how is Qubes
> configured? Does it make any assumptions that Vt-d is used instead of IOMMU
> or does it use any intel specific instructions?

Qubes is not a hypervisor, Qubes is only a user of Xen (true, with some
patches applied, by I pretty sure none of them is Intel-specific).

> As of my understanding
> currently Qubes is Linux(another OS could be used) on Dom0 with Xen and PV
> Fedoras(or other) in AppVM's. Correct me if I am mistaken but to me it
> seems it should run fine on AMD? Still there's only one report of a system
> that should have working IOMMU in the HCL, yet it's marked as NO.
>

Your reasoning sounds correct to me.

joanna.

[Hakisho Nukama]

Hey Mihail Ivanov,

can you elaborate which AMD board you mean?
Maybe the reporter didn't activate IOMMU inside the BIOS
and therefore the HCL report script did report a NO.
Or the BIOS APIC and/or IVRS tables are flawed.

I'm also in search of a motherboard with IOMMU and ECC
support.
This is a good starting point:
https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware

Best Regards,
Nukama

[Joanna Rutkowska]

Ok, one Intel-specific thing would be (optional) Anti Evil Maid 2.x
which uses tboot, which itself attempts to use Intel TXT for trusted
boot. But even AEM 2.x w/ tboot should work fine on a non-TXT machine,
albeit you would be able to seal to the BIOS-extended PCRs (in other
words: only static root of trust for AEM, and not including /boot -->
one should keep AEM on a separate stick).

joanna.

[Mihail Ivanov]

Hello, well the board I am talking about is GA-990FXA-UD5
As for why I think it works: 
people have stated so on the Xen mailing list
it's listed in that wikipedia page you've linked
also on the Xen website
and in some other forums

And last but not least I've found this and other videos which show PCI passthrough on it(which without IOMMU should be impossible)
https://www.youtube.com/watch?v=L_g7ZBMWoLk

As for the flawed tables - I hear that's the case on some ASUS boards and Asrock boards(Xen mailing list) as well, so I think I will stay away from them.
Still I see that many people have problems with the IVRS tables only on the newer versions of Xen(4.2+, saying that Xen has more strict checks now?) so I am not sure if it's that big of a deal.

Anyway those tables are a bios issue as far as I know. All 990FX mobos should have IOMMU.

As for the memory support - I've read some people claim they have ECC ram on that mobo.

There are issues with the ram through -  many say it can't support 4 DIMMS on freq > 1600(defaults on 1333), and they say the it's a problem of the chipset.

[Mihail Ivanov]

Hello, I feel honored to get a direct response from the founder of Qubes herself :)

As uneducated as I might be I'd mostly post questions:

You're saying TXT offers DRTM, but AMD has an equivalent technology, shouldn't it be possible to use DRTM with AMD?

http://xmhf.sourceforge.net/doc/xmhf/doc/drtm-design.md.html

Is AMD's variant as insecure as TXT?(btw the mainboard I am talking about has a TPM header but the TPM chip costs a lot).

You're saying using AEM with SRTM will not be able to check /boot(or I am misunderstanding something)? 

But then it can only check the BIOS, correct?(based on the PCRs).

[Joanna Rutkowska]

On 05/30/14 16:02, Mihail Ivanov wrote:
> Hello, I feel honored to get a direct response from the founder of Qubes
> herself :)
>

:)

> As uneducated as I might be I'd mostly post questions:
>
> You're saying TXT offers DRTM, but AMD has an equivalent technology,
> shouldn't it be possible to use DRTM with AMD?
> http://xmhf.sourceforge.net/doc/xmhf/doc/drtm-design.md.html
>

It should be possible, but AFAIK tboot that we use in AEM happens to
support only Intel TXT (which is not surprising given that it's an
Intel's sponsored project)

> Is AMD's variant as insecure as TXT?(btw the mainboard I am talking about
> has a TPM header but the TPM chip costs a lot).
>

I've never had a chance to play with the AMD technology. Probably
because in the times when we've been doing all our epic Trusted
Computing offensive research Intel had 99% of laptops market. Not sure
if anything changed recently?

> You're saying using AEM with SRTM will not be able to check /boot(or I am
> misunderstanding something)?

Yes, because in Qubes R2 we use GRUB2 which has no support for SRTM. In
AEM v1.x on Qubes R1 we used Trusted Boot, which implemented SRTM (i.e.
was able to extend the trust chain initiated by the BIOS by extending
PCRs with hashes of each of the code that it was about to execute).
Unfortunately Trusted Grub has become a dead project and for reasons
which I don't recall ATM we couldn't use it after we upgraded to newer
distro in Dom0.

> But then it can only check the BIOS, correct?(based on the PCRs).
>

Most today BIOSes should implement SRTM[*], so you should be able to use
AEM to verify your system using the PCRs that are used by the BIOS to
hash the code it's executing (i.e. seal AEM secret to those PCRs only).

Cheers,
joanna.

[*] Whether they do that correctly or not is a different questions ;)

[Mihail Ivanov]

Greetings Joanna,

I've looked all around and found some information regarding the AMD technology.
This book seems interesting http://my.safaribooksonline.com/book/networking/security/9780132398428

Gonna read it after I am done with the Xen book(thank you for recommending it in the developer books section)

Also this interesting project called Flicker which works on both Intel and AMD(stated in its info in Hardware reqs):

http://sourceforge.net/projects/flickertcb/

https://sparrow.ece.cmu.edu/group/flicker.html

Hope you find this info useful(sorry for wasting your time if you have read it already).

Now from the Trusted Grub's readme:

"Due to the PC architecture, the size of the boot sector (where stage1 is

located) is limited to 512 bytes. But the original stage1 is already very

close to this limit, leaving very few space for the TCG extensions. Because

of this, it was necessary (in the current version of TrustedGRUB) to eliminate the CHS-

code. This results in the problem that we support only LBA-discs now."

Aren't all disks nowadays LBA? So this probably isn't why you dropped support for it?

Isn't like we just add more code and build a chain of hashes?

Assuming upgrading to a new distro just brings in a new kernel and a different initramfs I can't think of a reason why it shouldn't work... if it once did.

"TrustedGRUB treats Xen as a modified Linux, thus it is possible to boot and measure Xen (At least the kernel for Dom-0)."

Unless there is a problem with a newer version of Xen?

Now it's obvious Trusted GRUB is MBR only so it doesn't support UEFI, so maybe that is the reason for the drop?(but I think tboot is MBR only as well..)

Cheers