linux-kernel - Re: "x86: Remove Intel MPX" is wrong (Re: linux-next: manual merge of the kvm tree with the tip tree)

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: <c1c1d927-9e7c-3937-4ea9-a6d6dd94a4ee@intel.com>
Date:   Wed, 19 Dec 2018 13:28:58 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Radim Krčmář <rkrcmar@...hat.com>,
        KVM <kvm@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Marc Orr <marcorr@...gle.com>
Subject: Re: "x86: Remove Intel MPX" is wrong (Re: linux-next: manual merge of
 the kvm tree with the tip tree)


On 12/19/18 1:00 PM, Paolo Bonzini wrote:
> On 19/12/18 21:54, Dave Hansen wrote:
>> I should have called this out in the changelog, but I removed *all* the
>> support because I assumed that guests don't need MPX because no other OS
>> supported it that I know of.
> 
> Well, as long as you could have code that sets the MPX bits in XCR0, KVM
> will have to support it.  My employer happens to sell one such kernel
> and will probably do so a little less than ten years from now. :)

Does your employer sell a system that supports live migration across
major releases?  Or, is it always that you support migration to _newer_
releases but not older?

>>> A simple fix would be to leave the XSAVE state enabled in the kernel
>>> unconditionally even if all the other gunk is removed; alternatively
>>> I can also try to save/restore it only for the guest FPU.
>>
>> We could do this in two phases: remove the APIs now, and then remove the
>> XSAVE enabling later (4.22 or whenever).
>>
>> But, on the other hand, if we want to remove XSAVE support for MPX,
>> we'll have to break live migration at _some_ point, so why not just do
>> it now?
> 
> In fact I'm not sure we want to ever remove XSAVE support for MPX in KVM
> as long as the processor supports it.  That is, when KVM does
> xsave/xrstor of the guest_fpu, we probably want to include MPX in there.
> That can be contained within KVM, Linux need not enable it in XCR0, 

I believe you need the feature bit set in XCR0 for XSAVE* to be able to
operate on it.  So, you could do this, but you would need to save XCR0,
set the XCR0 MPX bits, do XSAVE or XRSTOR, and restore XCR0 all with
preemption (and interrupts?) off.

You could just open-code the MPX save/restore, though.  MPX is
XSAVE-managed, but not XSAVE-enabled like some other features, IIRC.