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.
