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]

Message-ID: <db4e00d5-0cec-d50a-7dae-2ca9808bc187@intel.com>
Date:   Fri, 1 Apr 2022 12:25:22 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Bharata B Rao <bharata@....com>, Andy Lutomirski <luto@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:     linux-mm@...ck.org, the arch/x86 maintainers <x86@...nel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, shuah@...nel.org,
        Oleg Nesterov <oleg@...hat.com>, ananth.narayan@....com
Subject: Re: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging

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.

...
> However given that without a hardware feature like ARM64 MTE, this would
> primarily be used in non-production environments. Hence I wonder if MSR
> write cost could be tolerated?

It would be great of the mysterious folks who asked both Intel and AMD
for this feature could weigh in on this thread.  But, I've been assuming
that these features will be used to accelerate address sanitizers which
used heavily today in non-production environments but are (generally)
too slow for production.

I'd be very surprised if folks wanted this snazzy new hardware feature
from every CPU vendor on the planet just to speed up their
non-production environments.

I'd be less surprised if they wanted to expand the use of pointer
tagging into more production environments.