+Elena On 2024-11-01 at 16:06+0000, Dave Hansen wrote: > 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. [...] > > 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. Right, the only attacks we can thwart with direct map removal are transient execution attacks on the host kernel whose leak origin is "Mapped memory" in Table 1 of the Quarantine paper [2]. Maybe the simplest hypothetical to consider here is a new spectre v1 gadget in the host kernel. > 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. > > 1. https://cdrdv2.intel.com/v1/dl/getContent/733575 Thank you, I hadn't seen that. That is a very strong claim as far as preventing speculative access; I didn't realize Intel claimed that about TDX. The comma followed by "to detect if a prior corruption attempt was successful" makes me wonder a bit if the statement is not quite as broad as it sounds, but maybe that's just meant to relate it to the integrity section? > 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. Fair enough. It hasn't been clear to me if there is a machine check when the host kernel accesses guest memory only transiently. I was assuming there is not. But if other mitigations completely prevent even speculative access of TD private memory like you're saying, then agree nothing to gain from direct map removal in the TDX case. Derek [2] https://download.vusec.net/papers/quarantine_raid23.pdf
