linux-kernel - Re: [RFC, PATCHv1 00/28] 5-level paging

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]

Date:   Tue, 13 Dec 2016 13:06:35 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Ingo Molnar <mingo@...nel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
        "H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
        Andy Lutomirski <luto@...capital.net>,
        linux-arch@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC, PATCHv1 00/28] 5-level paging

On 12/08/2016 09:01 PM, Ingo Molnar wrote:
>> >   - Handle opt-in wider address space for userspace.
>> > 
>> >     Not all userspace is ready to handle addresses wider than current
>> >     47-bits. At least some JIT compiler make use of upper bits to encode
>> >     their info.
>> > 
>> >     We need to have an interface to opt-in wider addresses from userspace
>> >     to avoid regressions.
>> > 
>> >     For now, I've included testing-only patch which bumps TASK_SIZE to
>> >     56-bits. This can be handy for testing to see what breaks if we max-out
>> >     size of virtual address space.
> So this is just a detail - but it sounds a bit limiting to me to provide an 'opt 
> in' flag for something that will work just fine on the vast majority of 64-bit 
> software.

MPX is going to be a real pain here.  It is relatively transparent to
applications that use it, and old MPX binaries are entirely incompatible
with the new address space size, so an opt-out wouldn't be friendly.

Because the top-level MPX bounds table is indexed by the virtual
address, a growth in vaddr space is going to require the table to grow
(or change somehow).  The solution baked into the hardware spec is to
just make the top-level table 512x larger to accommodate the 512x
increase in vaddr space.  (This behavior is controlled by a new MSR, btw...)

So, either we disable MPX on all old MPX binaries by returning an error
when the prctl() tries to enable MPX and 5-level paging is on, or we go
with some form of an opt-in.  New MPX binaries will opt-in to the larger
address space since they know to allocate the new, larger table.