[RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

[Dave Hansen]

On 10/31/24 17:10, Manwaring, Derek wrote:
> TDX and SEV encryption happens between the core and main memory, so
> cached guest data we're most concerned about for transient execution
> attacks isn't necessarily inaccessible.
> 
> I'd be interested what Intel, AMD, and other folks think on this, but I
> think direct map removal is worthwhile for CoCo cases as well.

I'm not sure specifically which attacks you have in mind.  Also, don't
forget that TDX doesn't get any intra-system security from encryption
itself.  All that the encryption does is prevent some physical attacks.

The main thing I think you want to keep in mind is mentioned in the "TDX
Module v1.5 Base Architecture Specification"[1]:

> Any software except guest TD or TDX module must not be able to
> speculatively or non-speculatively access TD private memory,

That's a pretty broad claim and it involves mitigations in hardware and
the TDX module.

I _think_ you might be thinking of attacks like MDS where some random
microarchitectural buffer contains guest data after a VM exit and then
an attacker extracts it.  Direct map removal doesn't affect these
buffers and doesn't mitigate an attacker getting the data out.  TDX
relies on other defenses.

As for the CPU caches, direct map removal doesn't help or hurt anything.
 A malicious VMM would just map the guest data if it could and try to
extract it if that were possible.  If the attack is mitigated when the
data is _mapped_, then it's certainly not possible _unmapped_.

So why bother with direct map removal for TDX?  A VMM write to TD
private data causes machine checks.  So any kernel bug that even
accidentally writes to kernel memory can bring the whole system down.
Not nice.

1. https://cdrdv2.intel.com/v1/dl/getContent/733575