From: Bharata B Rao <bharata@amd.com> > Sent: 10 March 2022 11:16 > > This patchset makes use of Upper Address Ignore (UAI) feature available > on upcoming AMD processors to provide user address tagging support for x86/AMD. > > 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 > > https://bugzilla.kernel.org/attachment.cgi?id=300549 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. Otherwise the best thing is just to change access_ok() to only reject addresses with the top bit set. Then you shouldn't need any extra tests in the fast-path of access_ok(). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
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 >> >> https://bugzilla.kernel.org/attachment.cgi?id=300549 > 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. 1. https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
From: Dave Hansen <dave.hansen@intel.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 > >> > >> https://bugzilla.kernel.org/attachment.cgi?id=300549 > > 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. Otherwise for 64bit access_ok() need only test address < 0 and rely on kernel code reading something below the (big) offset to valid kernel addresses. No real need to include the length at all. If the hardware is just ignoring the high address bits then the should be no need to mask them in kernel. The required kernel accesses to user memory should 'just work'. Of course, the bit to enable this (wherever it is) needs to be restored on every process switch. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On 3/10/2022 10:49 PM, David Laight wrote: > From: Dave Hansen <dave.hansen@intel.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 >>>> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fattachment.cgi%3Fid%3D300549&data=04%7C01%7Cbharata%40amd.com%7Ca1de24223931481b3fcb08da02ba2e6f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637825295938946622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HijEAUq172r8YwkcCuhvl99Vk5BwE6iSROXcSQXmJHk%3D&reserved=0 >>> 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? 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? Regards, Bharata.
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@intel.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)
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@intel.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. Regards, Bharata.
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@intel.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)
On 3/11/22 01:36, David Laight wrote: > 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. I can't believe I need to say this: Wikipedia is not an authoritative source about what anyone is going to do with their CPUs in the future. Please don't base any Linux decisions off this information.
© 2016 - 2026 Red Hat, Inc.