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

[Dave Hansen <dave.hansen@intel.com>]

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.