linux-hardening - Re: [PATCH] usercopy: use unsigned long instead of uintptr

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]

Date:   Thu, 16 Jun 2022 16:21:48 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-mm@...ck.org, linux-xfs@...r.kernel.org,
        linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
        Uladzislau Rezki <urezki@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Joe Perches <joe@...ches.com>
Subject: Re: [PATCH] usercopy: use unsigned long instead of uintptr_t

On Thu, Jun 16, 2022 at 04:51:08PM +0200, Jason A. Donenfeld wrote:
> For better or for worse, I've always assumed that the kernel had its
> reasons -- legitimate reasons, even -- for preferring `unsigned long` to
> a userspace type like `uintptr_t`, so I've always tried to code that
> way.

I don't know why people call uintptr_t a "userspace type".  It's a type
invented by C99 that is an integer type large enough to hold a pointer.
Which is exactly what we want here.

> If that's a "dinosaur approach" that "has to stop", it'd certainly be
> news to me (and I'm guessing others on the list too). I've never really
> seen anybody question the kernel's `unsigned long` usage before.

I've put in a proposal to ksummit-discuss that makes the case for using
uintptr_t where it fits our needs.  Here's a copy of it.

--- 8< ---

Zettalinux: It's Not Too Late To Start

The current trend in memory sizes lead me to believe that we'll need
128-bit pointers by 2035.  Hardware people are starting to think about it
[1a] [1b] [2].  We have a cultural problem in Linux where we believe that
all pointers (user or kernel) can be stuffed into an unsigned long and
newer C solutions (uintptr_t) are derided as "userspace namespace mess".

The only sane way to set up a C environment for a CPU with 128-bit
pointers is sizeof(void *) == 16, sizeof(short) == 2, sizeof(int) == 4,
sizeof(long) == 8, sizeof(long long) == 16.

That means that casting a pointer to a long will drop the upper 64
bits, and we'll have to use long long for the uintptr_t on 128-bit.
Fixing Linux to be 128-bit clean is going to be a big job, and I'm not
proposing to do it myself.  But we can at least start by not questioning
when people use uintptr_t inside the kernel to represent an address.

Getting the userspace API fixed is going to be the most important thing
(eg io_uring was just added and is definitely not 128-bit clean).
Fortunately, no 128-bit machines exist today, so we have a bit of time
to get the UAPI right.  But if not today, then we should start soon.

There are two purposes for this session:

 * Agree that we do need to start thinking about 128-bit architectures
   (even if they're not going to show up in our offices tomorrow)
 * Come to terms with needing to use uintptr_t instead of unsigned long

[1a] https://github.com/michaeljclark/rv8/blob/master/doc/src/rv128.md
[1b] https://github.com/riscv/riscv-opcodes/blob/master/unratified/rv128_i
[2] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/