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]

Message-ID: <20220712105419.GB2805143@chaop.bj.intel.com>
Date:   Tue, 12 Jul 2022 18:54:19 +0800
From:   Chao Peng <chao.p.peng@...ux.intel.com>
To:     Chao Gao <chao.gao@...el.com>
Cc:     Isaku Yamahata <isaku.yamahata@...il.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 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.

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

Chao
> 
> Maybe I am misunderstanding something?