linux-kernel - Re: [PATCH v3 12/19] x86/vmx: Introduce VMX_FEATURES

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20191122190927.GB31235@linux.intel.com>
Date:   Fri, 22 Nov 2019 11:09:27 -0800
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Tony Luck <tony.luck@...el.com>,
        Tony W Wang-oc <TonyWWang-oc@...oxin.com>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, linux-edac@...r.kernel.org,
        linux-kselftest@...r.kernel.org,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Subject: Re: [PATCH v3 12/19] x86/vmx: Introduce VMX_FEATURES_*

On Fri, Nov 22, 2019 at 07:36:41PM +0100, Borislav Petkov wrote:
> On Thu, Nov 21, 2019 at 01:50:17PM -0800, Sean Christopherson wrote:
> > As for why I want to keep these out of cpu_has()... VMX has a concept of
> > features being fixed "on", e.g. early CPUs don't allow disabling off CR3
> > interception.  A cpu_has() approach doesn't work well since it loses the
> > information regarding which bits are fixed-1.  KVM also has several module
> > params that can be used to disable use of features, i.e. we don't want
> > cpu_has() for VMX features because the KVM-specific variables need to be
> > the canonical reference.
> 
> Well, you can use the cpu_has() machinery for stuff like that too - we
> can clear bits there too: clear_cpu_cap() - and since clearing those
> bits are only for /proc/cpuinfo reporting, it's not like anything would
> break if that flag is gone. Just saying, in case you want to use the
> machinery for that.

It doesn't fit the KVM use case very well.  There is an obnoxious amount
of legacy KVM code that exists only to support old processors (10+ years
old), but that we can't get rid of because people are still actively
running KVM on old hardware.  KVM provides module params so that we can
easily test those flows on modern hardware, e.g. for certain changes I'll
reload and retest KVM 2-3 times with different settings.

In theory we could do something like recompute VMX_FEATURE_* when KVM is
loaded, but that'd be a bit ugly and there are also tenative plans to move
the relevant module params under an ioctl() so that they can be toggled on
a per-VM basis to help automate testing, and IIRC for customers running
certain legacy workloads alongside normal VMs

> And that would avoid some of the duplication of having KVM-specific
> variables *and* VMX_FEATURE_* flags, where latter are not really
> toggleable but only for /proc/cpuinfo. Especially if you wanna enforce
> "developers to define a VMX_FEATURE flag when adding support for a new
> hardware feature."