From patchwork Tue Jul 9 16:02:01 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 13728314 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 84DE3C2BD09 for ; Tue, 9 Jul 2024 16:11:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=i0JF7oJ2UZKiui7uzhM+GaLMaLwkd8+GLmc/jcTKWtw=; b=NQuTGr6gdJqCf5Yuxdf+ms2ONs tssBq4qji2H9Ec5345BnPGjfv1zTbpg+jQK/4DStI+7ip5RGEmrMCqfsWjYpumal+sHI8is1xsKgi BvyA6iAES/RrjIO+Sed66t5c3J/7ZIvIq9iCPlva5mLuKQl+oJuvDWCkLg7IJpysOs664uPTDdXZA 63yP0bpVVe4z9eSMAnyQUbdRRNhpp5lQgK0UbXHqR8/sUMv86viSebR+OMZQFQZd7MmSwrfiu7tLO wpxUMsEGHecgUCo5SoqPxWtbw1PkK2uFhy9F1249SnS0Cl2nnkSpgGoCX3vpT7j15fikMqIW9xHh1 d9lC+SVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRDR7-00000007sLt-0QSJ; Tue, 09 Jul 2024 16:11:25 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRDQE-00000007s3U-3Tlr for linux-arm-kernel@lists.infradead.org; Tue, 09 Jul 2024 16:10:32 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 47BE8614BC; Tue, 9 Jul 2024 16:10:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7941C3277B; Tue, 9 Jul 2024 16:10:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1720541430; bh=JiF3RZjwFHTLjremsIUGtIRqMKzbsREZpa5fiAqC1ow=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Sa7bTIPVrn0CUv6vDC7OChbTajY29wYE/7+U6H0Vn9mq+8k6AHett6yCoa9OJR/dY /XyzjirShHcyQx9Yke22ftV55PkuRa7zQFPxJrRRexu4OGqEhE1z9qCwOfMG4cJaww LTrkTEqVfzTy5RSeOWV9w2ZIFoAkKHSLnYDzCKAY= From: Linus Torvalds To: Mark Rutland Cc: Linux ARM , Linus Torvalds Subject: [PATCH 3/3] arm64: access_ok() optimization Date: Tue, 9 Jul 2024 09:02:01 -0700 Message-ID: <20240709161022.1035500-4-torvalds@linux-foundation.org> X-Mailer: git-send-email 2.45.1.209.gc6f12300df In-Reply-To: <20240709161022.1035500-1-torvalds@linux-foundation.org> References: <20240709161022.1035500-1-torvalds@linux-foundation.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240709_091031_014773_F64A3CB7 X-CRM114-Status: GOOD ( 19.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The TBI setup on arm64 is very strange: HW is set up to always do TBI, but the kernel enforcement for system calls is purely a software contract, and user space is supposed to mask off the top bits before the system call. Except all the actual brk/mmap/etc() system calls then mask it in kernel space anyway, and accept any TBI address. This basically unifies things and makes access_ok() also ignore it. This is an ABI change, but the current situation is very odd, and this change avoids the current mess and makes the kernel more permissive, and as such is unlikely to break anything. The way forward - for some possible future situation when people want to use more bits - is probably to introduce a new "I actually want the full 64-bit address space" prctl. But we should make sure that the software and hardware rules actually match at that point. Signed-off-by: Linus Torvalds --- arch/arm64/include/asm/uaccess.h | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h index 28f665e0975a..1f21190d4db5 100644 --- a/arch/arm64/include/asm/uaccess.h +++ b/arch/arm64/include/asm/uaccess.h @@ -30,23 +30,20 @@ static inline int __access_ok(const void __user *ptr, unsigned long size); /* * Test whether a block of memory is a valid user space address. - * Returns 1 if the range is valid, 0 otherwise. * - * This is equivalent to the following test: - * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX + * We only care that the address cannot reach the kernel mapping, and + * that an invalid address will fault. */ -static inline int access_ok(const void __user *addr, unsigned long size) +static inline int access_ok(const void __user *p, unsigned long size) { - /* - * Asynchronous I/O running in a kernel thread does not have the - * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag - * the user address before checking. - */ - if (IS_ENABLED(CONFIG_ARM64_TAGGED_ADDR_ABI) && - (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR))) - addr = untagged_addr(addr); + unsigned long addr = (unsigned long)p; - return likely(__access_ok(addr, size)); + /* Only bit 55 of the address matters */ + addr |= addr+size; + addr = (addr >> 55) & 1; + size >>= 55; + + return !(addr | size); } #define access_ok access_ok