On 2024-11-01 at 17:20+0000, Dave Hansen wrote: > On 11/1/24 09:56, Manwaring, Derek wrote: > > 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. Yeah that makes a lot of sense. I just view the ideal outcome as a composition of strong, independent defenses. So as a guest you have the confidentiality and integrity guarantees of the hardware, *and* you have an up-to-date, good-hygiene (albeit not attested) host kernel just in case some crazy attack/gap comes up.