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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Sean Christopherson <seanjc@xxxxxxxxxx>
> Sent: Friday, November 1, 2024 10:18 AM
> To: Derek Manwaring <derekmn@xxxxxxxxxx>
> Cc: roypat@xxxxxxxxxxxx; ackerleytng@xxxxxxxxxx;
> agordeev@xxxxxxxxxxxxx; aou@xxxxxxxxxxxxxxxxx;
> borntraeger@xxxxxxxxxxxxx; bp@xxxxxxxxx; catalin.marinas@xxxxxxx;
> chenhuacai@xxxxxxxxxx; corbet@xxxxxxx; dave.hansen@xxxxxxxxxxxxxxx;
> david@xxxxxxxxxx; gerald.schaefer@xxxxxxxxxxxxx; gor@xxxxxxxxxxxxx;
> graf@xxxxxxxxxx; hca@xxxxxxxxxxxxx; hpa@xxxxxxxxx;
> jgowans@xxxxxxxxxx; jthoughton@xxxxxxxxxx; kalyazin@xxxxxxxxxx;
> kernel@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-kselftest@xxxxxxxxxxxxxxx; linux-
> mm@xxxxxxxxx; linux-riscv@xxxxxxxxxxxxxxxxxxx; linux-s390@xxxxxxxxxxxxxxx;
> linux-trace-kernel@xxxxxxxxxxxxxxx; loongarch@xxxxxxxxxxxxxxx;
> luto@xxxxxxxxxx; mathieu.desnoyers@xxxxxxxxxxxx; mhiramat@xxxxxxxxxx;
> mingo@xxxxxxxxxx; palmer@xxxxxxxxxxx; paul.walmsley@xxxxxxxxxx;
> pbonzini@xxxxxxxxxx; peterz@xxxxxxxxxxxxx; quic_eberman@xxxxxxxxxxx;
> rostedt@xxxxxxxxxxx; rppt@xxxxxxxxxx; shuah@xxxxxxxxxx;
> svens@xxxxxxxxxxxxx; tabba@xxxxxxxxxx; tglx@xxxxxxxxxxxxx;
> vannapurve@xxxxxxxxxx; will@xxxxxxxxxx; x86@xxxxxxxxxx;
> xmarcalx@xxxxxxxxxx; Kaplan, David <David.Kaplan@xxxxxxx>
> 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





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux