linux-kernel - RE: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging

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]

Date:   Fri, 11 Mar 2022 09:36:21 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Bharata B Rao' <bharata@....com>,
        'Dave Hansen' <dave.hansen@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "oleg@...hat.com" <oleg@...hat.com>,
        "ananth.narayan@....com" <ananth.narayan@....com>
Subject: RE: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging

From: Bharata B Rao
> Sent: 11 March 2022 09:11
> 
> On 3/11/2022 1:45 PM, David Laight wrote:
> > From: Bharata B Rao
> >> Sent: 11 March 2022 05:43
> >> On 3/10/2022 10:49 PM, David Laight wrote:
> >>> From: Dave Hansen <dave.hansen@...el.com>
> >>>> Sent: 10 March 2022 16:46
> >>>>
> >>>> On 3/10/22 06:32, David Laight wrote:
> >>>>>> UAI allows software to store a tag in the upper 7 bits of a logical
> >>>>>> address [63:57]. When enabled, the processor will suppress the
> >>>>>> traditional canonical address checks on the addresses. More information
> >>>>>> about UAI can be found in section 5.10 of 'AMD64 Architecture
> >>>>>> Programmer's Manual, Vol 2: System Programming' which is available from
> >>>>>>
> > ,,,
> >>>>> Is that really allowing bit 63 to be used?
> >>>>> That is normally the user-kernel bit.
> >>>>> I can't help feeling that will just badly break things.
> >>>>
> >>>> Yeah, this does seem worrisome.  The LAM approach[1] retains
> >>>> canonicality checking for bit 63.
> >>>
> >>> Actually it is rather worse than 'worrisome'.
> >>> Allowing the user all address upto the base of the valid
> >>> kernel addresses (probably tags to 3e, but not 3f)
> >>> means that you can't use a fast address check in access_ok().
> >>> You are forced to use the strict test that 32bit kernels use.
> >>
> >> From what I see, there is a single implementation of access_ok()
> >> in arch/x86/asm/include/uaccess.h that does check if the user
> >> address+size exceeds the limit.
> >>
> >> Guess I am missing something, but can you please point me to the fast
> >> implementation(that benefits from bit 63 being user/kernel address
> >> disambiguation bit) and the strict checking in 32bit kernels that
> >> are you are referring to?
> >
> > You can just check ((address | size) >> 62) on 64bit arch that
> > use bit 63 to select user/kernel and have a massive address
> > hole near the boundary.
> > The compiler optimises out constant size from that calculation.
> > On x86-64 non-canonical addresses give a different fault
> > to 'page not present' - but that can be handled.
> 
> Ok, so are you mentioning about a future optimization to access_ok()
> that could benefit by retaining bit 63 as kernel/user bit?
> 
> Since you said using bit 63 to store metadata will break things,
> I was trying to understand how and where does it break.

Kernel addresses start at 0xffxxx (for 57bit, 5 level page tables).
(Maybe the valid ones are still 0xffff8xxx.)
so you really don't want userspace using those to alias valid user
addresses.

I'm not entirely sure what enabling UAI does.
But the user page tables have to contain mappings for some kernel
addresses (even with page table separation).
Also you really don't want to have to mask off the high address
bits before a kernel access to the use buffer.
So it isn't really obvious how addresses that start 0xff can be used.
and that rather implies you can use bit 63 at all (without horrid
logic in some (probably) very critical hardware timing paths.

Wikipedia also notes:
    Intel has implemented a scheme with a 5-level page table, which allows
    Intel 64 processors to support a 57-bit virtual address space.
    Further extensions may allow full 64-bit virtual address space and
    physical memory by expanding the page table entry size to 128-bit,
    and reduce page walks in the 5-level hierarchy by using a larger 64 KiB
    page allocation size that still supports 4 KiB page operations for
    backward compatibility.
If they implement 64K pages then you lose the extra bits.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)