linux-kernel - Re: [RFC PATCH 00/13] XOM for KVM guest userspace

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: <bc025a4f-2128-24ed-e5b7-76802f22cd53@redhat.com>
Date:   Fri, 4 Oct 2019 09:22:42 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Rick Edgecombe <rick.p.edgecombe@...el.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, x86@...nel.org, linux-mm@...ck.org,
        luto@...nel.org, peterz@...radead.org, dave.hansen@...el.com,
        sean.j.christopherson@...el.com, keescook@...omium.org
Cc:     kristen@...ux.intel.com, deneen.t.dock@...el.com
Subject: Re: [RFC PATCH 00/13] XOM for KVM guest userspace

On 03/10/19 23:23, Rick Edgecombe wrote:
> Since software would have previously received a #PF with the RSVD error code
> set, when the HW encountered any set bits in the region 51 to M, there was some
> internal discussion on whether this should have a virtual MSR for the OS to turn
> it on only if the OS knows it isn't relying on this behavior for bit M. The
> argument against needing an MSR is this blurb from the Intel SDM about reserved
> bits:
> "Bits reserved in the paging-structure entries are reserved for future
> functionality. Software developers should be aware that such bits may be used in
> the future and that a paging-structure entry that causes a page-fault exception
> on one processor might not do so in the future."
> 
> So in the current patchset there is no MSR write required for the guest to turn
> on this feature. It will have this behavior whenever qemu is run with
> "-cpu +xo".

I think the part of the manual that you quote is out of date.  Whenever
Intel has "unreserved" bits in the page tables they have done that only
if specific bits in CR4 or EFER or VMCS execution controls are set; this
is a good thing, and I'd really like it to be codified in the SDM.

The only bits for which this does not (and should not) apply are indeed
bits 51:MAXPHYADDR.  But the SDM makes it clear that bits 51:MAXPHYADDR
are reserved, hence "unreserving" bits based on just a QEMU command line
option would be against the specification.  So, please don't do this and
introduce an MSR that enables the feature.

Paolo