From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08797C433EF for ; Thu, 16 Jun 2022 15:21:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 653036B0071; Thu, 16 Jun 2022 11:21:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DC3A6B0074; Thu, 16 Jun 2022 11:21:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47B876B0078; Thu, 16 Jun 2022 11:21:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3340D6B0071 for ; Thu, 16 Jun 2022 11:21:54 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 07CD810F5 for ; Thu, 16 Jun 2022 15:21:54 +0000 (UTC) X-FDA: 79584464148.19.6048B90 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 8DEFC1A0096 for ; Thu, 16 Jun 2022 15:21:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Xzaqf0G5xz9szgUM5cKTV6OKXPaivC3g3pX2zIMbtCc=; b=o1KXw2J/hq+bundzpPMlOfhF4y +CIj0K+uabqcY5aeW4lUpZn/dGZ16A2GSUYTRAs5Nevo1Uvb2Cn0vmUwQkExopeqsBhAvPanQmgno RYPzUS659B5anxehAmFHMUD860/FzZXgGQIKxVaiYpJd0LOh2EiT6lOVTYtQoM28ce6+O1MiJ5kyB +oAita53Ro+MdUwQ+931Ol2lVz6etRl1PmSB5FLb8T8HIoCNrm/HbRYA3WW+d4HzXZrSfb61aZ//4 SdQBmkpiYmNjH5XTlCaTuovVq0geGtt3aIgfqYlU5lHJPJy3BI9aE8cpjiGDkN8ZP5TPZLoU07uii nVqGQq6w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1o1rJc-0022hm-Fh; Thu, 16 Jun 2022 15:21:48 +0000 Date: Thu, 16 Jun 2022 16:21:48 +0100 From: Matthew Wilcox To: "Jason A. Donenfeld" Cc: linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Kees Cook , Greg Kroah-Hartman , Linus Torvalds , Joe Perches Subject: Re: [PATCH] usercopy: use unsigned long instead of uintptr_t Message-ID: References: <20220616143617.449094-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655392913; a=rsa-sha256; cv=none; b=HY5LtqEmopghCr0E3aY/NklaF3TiBaZMqnfw76ZclKgwzuWlWEN46a4ipwKQiyKfyyYrmN QtRar7aFoylwxv8ZIuFnXRpcodYltsKAquu5On1GbC40g2xV185uhDoPHKgWVKGwDxwHT8 IdSGYU3cU/ukocV1KK13BBqdoe0pFR8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="o1KXw2J/"; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655392913; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Xzaqf0G5xz9szgUM5cKTV6OKXPaivC3g3pX2zIMbtCc=; b=yAnC5QHfVuVVZPGLHJicpBrzNriS+UG7llhGpyZmAx6NQjsJaUGJx3oP7jG1DpHkiURJJx XTFH5F4neo3HtV1XPZmxVpqtdmdeF2ySEGoZNjA2m0WV7g+mZgD3O5L4V+3Vf+kKCNrI4M 1ZoB/EsrcRJKTdmDL7+Y0QAVmA6l3js= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8DEFC1A0096 X-Stat-Signature: prbkr4yny6bqbo11qnjziww8zfzchjne Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="o1KXw2J/"; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspam-User: X-HE-Tag: 1655392912-887498 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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/