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 08:15:52 +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 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.

In practice you can (probably) even completely ignore the 'size'
and just error if the top bit of the address is set.
While accesses might not be completely sequential they aren't
going to jump over the non-canonical addresses.

> Also I wonder here why ARM64 TBI which also uses the full upper byte
> (including bit 63) for storing tag/metadata doesn't suffer from
> this same problem?

The user-kernel bit is lower down (something like bit 53) so the
tags are using separate bits.
Although that choice of user/kernel bit makes life hard elsewhere.

	David

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