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.