Michael S. Tsirkin
2021-Oct-12 21:30 UTC
[PATCH v5 16/16] x86/tdx: Add cmdline option to force use of ioremap_host_shared
On Tue, Oct 12, 2021 at 02:18:01PM -0700, Andi Kleen wrote:> > > Interesting. VT-d tradeoffs ... what are they? > > The connection to the device is not encrypted and also not authenticated. > > This is different that even talking to the (untrusted) host through shared > memory where you at least still have a common key.Well it's different sure enough but how is talking to host less secure? Cold boot attacks and such?> > Allowing hypervisor to write into BIOS looks like it will > > trivially lead to code execution, won't it? > > This is not about BIOS code executing. While the guest firmware runs it is > protected of course. This is for BIOS structures like ACPI tables that are > mapped by Linux. While AML can run byte code it can normally not write to > arbitrary memory.I thought you basically create an OperationRegion of SystemMemory type, and off you go. Maybe the OSPM in Linux is clever and protects some memory, I wouldn't know.> The risk is more that all the Linux code dealing with this hasn't been > hardened to deal with malicious input. > > -Andi-- MST
Andi Kleen
2021-Oct-15 05:50 UTC
[PATCH v5 16/16] x86/tdx: Add cmdline option to force use of ioremap_host_shared
> I thought you basically create an OperationRegion of SystemMemory type, > and off you go. Maybe the OSPM in Linux is clever and protects > some memory, I wouldn't know.I investigated this now, and it looks like acpi is using ioremap_cache(). We can hook into that and force non sharing. It's probably safe to assume that this is not used on real IO devices. I think there are still some other BIOS mappings that use just plain ioremap() though. -Andi