On 11/1/24 09:56, Manwaring, Derek wrote: ... >>> 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? I think it's just relating 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. Previous generations of hardware have had some nastiness in this area. Speculative accesses were (I think) logged in the machine check banks, but wouldn't raise an #MC. I believe TDX-capable hardware won't even log speculative accesses. > 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. Remember, guest unmapping is done in the VMM. The VMM is not trusted in the TDX (or SEV-SNP) model. If any VMM can harm the protections on guest memory, then we have a big problem. That isn't to say big problem can't happen. Say some crazy attack comes to light where the VMM can attack TDX if the VMM has mapping for a guest (or TDX module) memory. Crazier things have happened, and guest unmapping _would_ help there, if you trusted the VMM. Basically, I think guest unmapping only helps system security as a whole if you must _already_ trust the VMM.
