linux-kernel - Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

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: <CALCETrWxrvwjd1AQ3z9Vrg5mQctK9gA29Rgvxv99b2=jtMpQ-Q@mail.gmail.com>
Date:   Thu, 15 Sep 2016 16:18:54 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     Kyle Huey <me@...ehuey.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Robert O'Callahan" <robert@...llahan.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        David Vrabel <david.vrabel@...rix.com>,
        Juergen Gross <jgross@...e.com>, Borislav Petkov <bp@...e.de>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Huang Rui <ray.huang@....com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Len Brown <len.brown@...el.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Aravind Gopalakrishnan <aravind.gopalakrishnan@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
        Kristen Carlson Accardi <kristen@...ux.intel.com>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>,
        "moderated list:XEN HYPERVISOR INTERFACE" 
        <xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 1:38 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski <luto@...capital.net> wrote:
>>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey <me@...ehuey.com> wrote:
>>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>>> <dave.hansen@...ux.intel.com> wrote:
>>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>>
>>>> Is any of this useful to optimize away at compile-time?  We have
>>config
>>>> options for when we're running as a guest, and this seems like a
>>feature
>>>> that isn't available when running on bare metal.
>>>
>>> On the contrary, this is only available when we're on bare metal.
>>> Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
>>> suppresses MSR_PLATFORM_INFO's report of support for it).
>>
>>KVM could easily support this.  If rr starts using it, I think KVM
>>*should* add support, possibly even for older CPUs that don't support
>>the feature in hardware.
>>
>>It's too bad that x86 doesn't give us the instruction bytes on a
>>fault.  Otherwise we could lazily switch this feature.
>>
>>--Andy
>
> You can "always" examine the instruction bytes in memory... have to make sure you properly consider the impact of race conditions though.

I'd rather avoid needing to worry about those race conditions if at
all possible, though.  Intel and AMD both have fancy "decode assists"
and such -- it would be quite nice IMO if we could get the same data
exposed in the handlers of synchronous faults.

If Intel or AMD were to do this for real, presumably the rule would be
that any fault-class exception caused by a validly-decoded instruction
at CPL3 (so #PF and #GP would count but #DB probably wouldn't, and #DF
wouldn't either unless the initial fault did) would stash away the
faulting instruction and other entries would instead stash away
"nothing here".  Some pair of MSRs or new instruction would read out
information.  Then we could accurately emulate CPUID, we could
accurately emulate page-faulting instructions if we cared, etc.  All
of the relevant hardware must already mostly exist because VMX and SVM
both have this capability.

--Andy