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@xxxxxxxxx> >>>> 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.
