linux-kernel - Re: [PATCH v7 000/102] KVM TDX basic feature support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Jul 2022 15:37:07 +0800
From:   Chao Peng <chao.p.peng@...ux.intel.com>
To:     Isaku Yamahata <isaku.yamahata@...il.com>
Cc:     Chao Gao <chao.gao@...el.com>, isaku.yamahata@...el.com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>, chao.p.peng@...el.com
Subject: Re: [PATCH v7 000/102] KVM TDX basic feature support

On Tue, Jul 12, 2022 at 10:22:50AM -0700, Isaku Yamahata wrote:
> On Tue, Jul 12, 2022 at 06:54:19PM +0800,
> Chao Peng <chao.p.peng@...ux.intel.com> wrote:
> 
> > On Tue, Jul 12, 2022 at 01:07:20PM +0800, Chao Gao wrote:
> > > On Mon, Jul 11, 2022 at 08:17:01AM -0700, Isaku Yamahata wrote:
> > > >Hi. Because my description on large page support was terse, I wrote up more
> > > >detailed one.  Any feedback/thoughts on large page support?
> > > >
> > > >TDP MMU large page support design
> > > >
> > > >Two main discussion points
> > > >* how to track page status. private vs shared, no-largepage vs can-be-largepage
> > > 
> > > ...
> > > 
> > > >
> > > >Tracking private/shared and large page mappable
> > > >-----------------------------------------------
> > > >VMM needs to track that page is mapped as private or shared at 4KB granularity.
> > > >For efficiency of EPT violation path (****), at 2MB and 1GB level, VMM should
> > > >track the page can be mapped as a large page (regarding private/shared).  VMM
> > > >updates it on MapGPA and references it on the EPT violation path. (****)
> > > 
> > > Isaku,
> > > 
> > > + Peng Chao
> > > 
> > > Doesn't UPM guarantee that 2MB/1GB large page in CR3 should be either all
> > > private or all shared?
> > > 
> > > KVM always retrieves the mapping level in CR3 and enforces that EPT's
> > > page level is not greater than that in CR3. My point is if UPM already enforces
> > > no mixed pages in a large page, then KVM needn't do that again (UPM can
> > > be trusted).
> > 
> > The backing store in the UMP can tell KVM which page level it can
> > support for a given private gpa, similar to host_pfn_mapping_level() for
> > shared address.
> >
> > However, this solely represents the backing store's capability, KVM
> > still needs additional info to decide whether that can be safely mapped
> > as 2M/1G, e.g. all the following pages in the 2M/1G range should be all
> > private, currently this is not something backing store can tell.
> 
> This argument applies to shared GPA.  The shared pages is backed by normal file
> mapping with UPM.  When KVM is mapping shared GPA, the same check is needed.  So
> I think KVM has to track all private or all shared or no-largepage at 2MB/1GB
> level.  If UPM tracks shared-or-private at 4KB level, probably KVM may not need to
> track it at 4KB level.

Right, the same also applies to shared memory. All the info we need is
whether pages of a 2M range is all private/shared but not mixed. UPM v7
has code tracking that in KVM and previously versions we track that in
the backing store which has been discussed not a good idea.

Chao
> 
> 
> > Actually, in UPM v7 we let KVM record this info so one possible solution
> > is making use of it.
> > 
> >   https://lkml.org/lkml/2022/7/6/259
> > 
> > Then to map a page as 2M, KVM needs to check:
> >   - Memory backing store support that level
> >   - All pages in 2M range are private as we recorded through
> >     KVM_MEMORY_ENCRYPT_{UN,}REG_REGION
> >   - No existing partial 4K map(s) in 2M range
> -- 
> Isaku Yamahata <isaku.yamahata@...il.com>