From: Bharata B Rao <email@example.com>
To: Dave Hansen <firstname.lastname@example.org>,
Andy Lutomirski <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>
Cc: email@example.com, the arch/x86 maintainers <firstname.lastname@example.org>,
"Kirill A. Shutemov" <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>,
Ingo Molnar <email@example.com>, Borislav Petkov <firstname.lastname@example.org>,
Dave Hansen <email@example.com>,
Catalin Marinas <firstname.lastname@example.org>,
Will Deacon <email@example.com>,
firstname.lastname@example.org, Oleg Nesterov <email@example.com>,
Subject: Re: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging
Date: Tue, 5 Apr 2022 11:28:19 +0530 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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.
next prev parent reply other threads:[~2022-04-05 5:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 11:15 [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 1/6] mm, arm64: Update PR_SET/GET_TAGGED_ADDR_CTRL interface Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 2/6] x86/cpufeatures: Add Upper Address Ignore(UAI) as CPU feature Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 3/6] x86: Enable Upper Address Ignore(UAI) feature Bharata B Rao
2022-03-10 19:46 ` Andrew Cooper
2022-03-10 22:37 ` David Laight
2022-03-10 22:46 ` Dave Hansen
2022-03-11 12:37 ` Boris Petkov
2022-03-10 11:15 ` [RFC PATCH v0 4/6] x86: Provide an implementation of untagged_addr() Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 5/6] x86: Untag user pointers in access_ok() Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 6/6] x86: Add prctl() options to control tagged user addresses ABI Bharata B Rao
2022-03-10 14:32 ` [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging David Laight
2022-03-10 16:45 ` Dave Hansen
2022-03-10 17:19 ` David Laight
2022-03-11 5:42 ` Bharata B Rao
2022-03-11 8:15 ` David Laight
2022-03-11 9:11 ` Bharata B Rao
2022-03-11 9:36 ` David Laight
2022-03-11 16:51 ` Dave Hansen
2022-03-10 15:16 ` Dave Hansen
2022-03-10 15:22 ` Dave Hansen
2022-03-14 5:00 ` Bharata B Rao
2022-03-14 7:03 ` Dave Hansen
2022-03-21 22:29 ` Andy Lutomirski
2022-03-21 22:59 ` Thomas Gleixner
2022-03-22 5:31 ` David Laight
2022-03-23 7:48 ` Bharata B Rao
2022-04-01 19:25 ` Dave Hansen
2022-04-05 5:58 ` Bharata B Rao [this message]
2022-04-01 19:41 ` Andy Lutomirski
2022-04-05 8:14 ` Peter Zijlstra
2022-04-05 8:40 ` Bharata B Rao
2022-04-08 17:41 ` Catalin Marinas
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).