Message-ID:
 <LV3PR12MB9265A91412AFCF7B65AD0BA694562@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Fri, 1 Nov 2024 18:32:38 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Sean Christopherson <seanjc@...gle.com>, Derek Manwaring
	<derekmn@...zon.com>
CC: "roypat@...zon.co.uk" <roypat@...zon.co.uk>, "ackerleytng@...gle.com"
	<ackerleytng@...gle.com>, "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, "borntraeger@...ux.ibm.com"
	<borntraeger@...ux.ibm.com>, "bp@...en8.de" <bp@...en8.de>,
	"catalin.marinas@....com" <catalin.marinas@....com>, "chenhuacai@...nel.org"
	<chenhuacai@...nel.org>, "corbet@....net" <corbet@....net>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"david@...hat.com" <david@...hat.com>, "gerald.schaefer@...ux.ibm.com"
	<gerald.schaefer@...ux.ibm.com>, "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
	"graf@...zon.com" <graf@...zon.com>, "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
	"hpa@...or.com" <hpa@...or.com>, "jgowans@...zon.com" <jgowans@...zon.com>,
	"jthoughton@...gle.com" <jthoughton@...gle.com>, "kalyazin@...zon.com"
	<kalyazin@...zon.com>, "kernel@...0n.name" <kernel@...0n.name>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, "luto@...nel.org"
	<luto@...nel.org>, "mathieu.desnoyers@...icios.com"
	<mathieu.desnoyers@...icios.com>, "mhiramat@...nel.org"
	<mhiramat@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"palmer@...belt.com" <palmer@...belt.com>, "paul.walmsley@...ive.com"
	<paul.walmsley@...ive.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "quic_eberman@...cinc.com"
	<quic_eberman@...cinc.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
	"rppt@...nel.org" <rppt@...nel.org>, "shuah@...nel.org" <shuah@...nel.org>,
	"svens@...ux.ibm.com" <svens@...ux.ibm.com>, "tabba@...gle.com"
	<tabba@...gle.com>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"vannapurve@...gle.com" <vannapurve@...gle.com>, "will@...nel.org"
	<will@...nel.org>, "x86@...nel.org" <x86@...nel.org>, "xmarcalx@...zon.com"
	<xmarcalx@...zon.com>
Subject: RE: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Sean Christopherson <seanjc@...gle.com>
> Sent: Friday, November 1, 2024 10:18 AM
> To: Derek Manwaring <derekmn@...zon.com>
> Cc: roypat@...zon.co.uk; 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; rppt@...nel.org; 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; Kaplan, David <David.Kaplan@....com>
> Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> +David Kaplan
>
> On Thu, Oct 31, 2024, Derek Manwaring wrote:
> > On 2024-10-31 at 10:42+0000 Patrick Roy wrote:
> > > On Thu, 2024-10-31 at 09:50 +0000, David Hildenbrand wrote:
> > > > On 30.10.24 14:49, Patrick Roy wrote:
> > > >> Most significantly, I've reduced the patch series to focus only
> > > >> on direct map removal for guest_memfd for now, leaving the whole
> > > >> "how to do non-CoCo VMs in guest_memfd" for later. If this
> > > >> separation is acceptable, then I think I can drop the RFC tag in
> > > >> the next revision (I've mainly kept it here because I'm not
> > > >> entirely sure what to do with patches 3 and 4).
> > > >
> > > > Hi,
> > > >
> > > > keeping upcoming "shared and private memory in guest_memfd" in
> > > > mind, I assume the focus would be to only remove the direct map for
> private memory?
> > > >
> > > > So in the current upstream state, you would only be removing the
> > > > direct map for private memory, currently translating to
> "encrypted"/"protected"
> > > > memory that is inaccessible either way already.
> > > >
> > > > Correct?
> > >
> > > Yea, with the upcomming "shared and private" stuff, I would expect
> > > the the shared<->private conversions would call the routines from
> > > patch 3 to restore direct map entries on private->shared, and zap
> > > them on
> > > shared->private.
> > >
> > > But as you said, the current upstream state has no notion of "shared"
> > > memory in guest_memfd, so everything is private and thus everything
> > > is direct map removed (although it is indeed already inaccessible
> > > anyway for TDX and friends. That's what makes this patch series a
> > > bit awkward :( )
> >
> > 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.
>
> Removal of the direct map entries for guest private PFNs likely won't affect
> the ability of an attacker to glean information from the unencrypted data
> that's in the CPU caches, at least not on x86.  Both TDX and SEV steal physical
> address
> bit(s) for tagging encrypted memory, and unless things have changed on
> recent AMD microarchitectures (I'm 99.9% certain Intel CPUs haven't
> changed), those stolen address bits are propagated into the caches.  I.e. the
> encrypted and unencrypted forms of a given PFN are actually two different
> physical addresses under the hood.
>
> I don't actually know how SEV uses the stolen PA bits though.  I don't see
> how it simply be the ASID, because IIUC, AMD CPUs allow for more unique
> SEV-capable ASIDs than uniquely addressable PAs by the number of stolen
> bits.  But I would be very surprised if the tag for the cache isn't guaranteed to
> be unique per encryption key.
>
> David?

How the stolen PA bits are used is a microarchitectural implementation detail.  It is true that the tag will be unique per encryption key.  Beyond that, I'm not sure what other details are relevant to SW.

--David Kaplan

Powered by blists - more mailing lists