Virtualization - Oct 2021 - [PATCH v5 16/16] x86/tdx: Add cmdline option to force use of ioremap_host_shared

> 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.
> 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.

The risk is more that all the Linux code dealing with this hasn't been 
hardened to deal with malicious input.

-Andi

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