Re: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging

[Bharata B Rao <bharata@amd.com>]

On 4/2/2022 12:55 AM, Dave Hansen wrote:
> On 3/23/22 00:48, Bharata B Rao wrote:
>> Ok got that. However can you point to me a few instances in the current
>> kernel code where such assumption of high bit being user/kernel address
>> differentiator exists so that I get some idea of what it takes to
>> audit all such cases?
> 
> Look around for comparisons against TASK_SIZE_MAX.
> arch/x86/lib/putuser.S or something like arch_check_bp_in_kernelspace()
> come to mind.
> 
>> Also wouldn't the problem of high bit be solved by using only the
>> 6 out of 7 available bits in UAI and leaving the 63rd bit alone?
>> The hardware will still ignore the top bit, but this should take
>> care of the requirement of high bit being 0/1 for user/kernel in the
>> x86_64 kernel. Wouldn't that work?
> 
> I don't think so.
> 
> The kernel knows that a dereference of a pointer that looks like a
> kernel address that get kernel data.  Userspace must be kept away from
> things that look like kernel addresses.
> 
> Let's say some app does:
> 
> 	void *ptr = (void *)0xffffffffc038d130;
> 	read(fd, ptr, 1);
> 
> and inside the kernel, that boils down to:
> 
> 	put_user('x', 0xffffffffc038d130);
> 
> Today the kernels knows that 0xffffffffc038d130 is >=TASK_SIZE_MAX, so
> this is obviously naughty userspace trying to write to the kernel.  But,
> it's not obviously wrong if the high bits are ignored.
> 
> Like you said, we could, as a convention, check for the highest bit
> being set and use *that* to indicate a kernel address.  But, the sneaky
> old userspace would just do:
> 
> 	put_user('x', 0x7fffffffc038d130);
> 
> It would pass the "high bit" check since that bit is clear, but it still
> accesses kernel memory because UAI ignores the bit userspace just cleared.
> 
> I think the only way to get around this is to go find every single place
> in the kernel that does a userspace address check and ensure that it
> fully untags the pointer first.

Thanks Dave for the detailed explanation.

We are discussing these aspects with the hardware team to check the best
possible path forward.

Regards,
Bharata.