Message-ID: <51fe5ad1-7057-4d43-b92c-580d187d2aeb@intel.com>
Date: Fri, 1 Nov 2024 10:20:39 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Manwaring, Derek" <derekmn@...zon.com>
Cc: ackerleytng@...gle.com, agordeev@...ux.ibm.com, aou@...s.berkeley.edu,
 borntraeger@...ux.ibm.com, bp@...en8.de, catalin.marinas@....com,
 chenhuacai@...nel.org, corbet@....net, dave.hansen@...ux.intel.com,
 david@...hat.com, gerald.schaefer@...ux.ibm.com, gor@...ux.ibm.com,
 graf@...zon.com, hca@...ux.ibm.com, hpa@...or.com, jgowans@...zon.com,
 jthoughton@...gle.com, kalyazin@...zon.com, kernel@...0n.name,
 kvm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
 linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, loongarch@...ts.linux.dev,
 luto@...nel.org, mathieu.desnoyers@...icios.com, mhiramat@...nel.org,
 mingo@...hat.com, palmer@...belt.com, paul.walmsley@...ive.com,
 pbonzini@...hat.com, peterz@...radead.org, quic_eberman@...cinc.com,
 rostedt@...dmis.org, roypat@...zon.co.uk, rppt@...nel.org,
 seanjc@...gle.com, shuah@...nel.org, svens@...ux.ibm.com, tabba@...gle.com,
 tglx@...utronix.de, vannapurve@...gle.com, will@...nel.org, x86@...nel.org,
 xmarcalx@...zon.com, mlipp@...zon.at, canellac@...zon.at,
 elena.reshetova@...el.com
Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

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.

Powered by blists - more mailing lists