linux-kernel - Re: [RFC PATCH 09/13] x86/cpufeature: Add detection of KVM XO

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: <20191030145520.GA14391@linux.intel.com>
Date:   Wed, 30 Oct 2019 07:55:20 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc:     "keescook@...omium.org" <keescook@...omium.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "Dock, Deneen T" <deneen.t.dock@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [RFC PATCH 09/13] x86/cpufeature: Add detection of KVM XO

On Tue, Oct 29, 2019 at 04:52:08PM -0700, Edgecombe, Rick P wrote:
> On Tue, 2019-10-29 at 16:33 -0700, Kees Cook wrote:
> > On Thu, Oct 03, 2019 at 02:23:56PM -0700, Rick Edgecombe wrote:
> > > Add a new CPUID leaf to hold the contents of CPUID 0x40000030 EAX to
> > > detect KVM defined generic VMM features.
> > >
> > > The leaf was proposed to allow KVM to communicate features that are
> > > defined by KVM, but available for any VMM to implement.

This doesn't necessarily work the way you intend, KVM's base CPUID isn't
guaranteed to be 0x40000000.  E.g. KVM supports advertising itself as
HyperV *and* KVM, in which case KVM's CPUID base will be 0x40000100.

I think you're better off just making this a standard KVM CPUID feature.
If a different hypervisor wants to reuse guest support as is, it can
advertise KVM support at a lower priority.

Note, querying guest CPUID isn't straightforward in either case.  But,
KVM doesn't support disabling its other CPUID-base paravirt features, e.g.
KVM emulates the kvm_clock MSRs regardless of what userspace advertises to
the guest.  Depending on what changes are required in KVM's MMU, this may
also need to be a KVM-wide feature, i.e. controlled via a module param.

> > > Add cpu_feature_enabled() support for features in this leaf (KVM XO), and
> > > a pgtable_kvmxo_enabled() helper similar to pgtable_l5_enabled() so that
> > > pgtable_kvmxo_enabled() can be used in early code that includes
> > > arch/x86/include/asm/sparsemem.h.
> > >
> > > Lastly, in head64.c detect and this feature and perform necessary
> > > adjustments to physical_mask.
> >
> > Can this be exposed to /proc/cpuinfo so a guest userspace can determine
> > if this feature is enabled?
> >
> > -Kees
>
> Is there a good place to expose the information that the PROT_EXEC and
> !PROT_READ combo creates execute-only memory? This way apps can check one place
> for the support and not worry about the implementation whether it's this, x86
> pkeys, arm or other.

I don't think so?  Assuming there's no common method, it can be displayed
in /proc/cpuinfo by adding a synthetic bit, e.g. in Linux-defined word 8
(virtualization) instead of a dedicated word.  The bit can then be
set if the features exists and is enabled (by the guest).

I'd also name the feature EXEC_ONLY.  XO is unnecessarily terse IMO, and
including "KVM" in the name may be misconstrued as a host KVM feature and
will be flat out wrong if hardware ever supports XO natively.