From patchwork Mon Jun 10 20:48:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 13692422 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 9C6EBC27C5E for ; Mon, 10 Jun 2024 20:49:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=umwoNB6RKQ423Rmp5ELXgwtKFoSg8C13YEwVsMMEQoY=; b=vF6Ou8+cxbq34u ZnPKi3YgtQvY37tHYL9mwtcFTJah31yJyFRR7HSu4KKwH0DSCV8M8zA/+9/Ks8BGU5kDTrLsbsFm0 gamqLgy6EGtnRbX0vzS+OEfkW+bjx7SRtM9iSVKg6mc4jtLhEeH5QPXCdMbAW2dNaP9VLrXuX6nkr gWfmrIVjdLEoFAsfUM6KtF4Kd6WSCpL3urrCIiqHagNZBeG+chiGZPlRYKbFJLyS8B2X4Ic70ooVB MxgMPcPrxIfQsQwt2wNf/7v/92BhsMMIoH3yTPvH2ZFGYqUQwVJkz+vSZOPhcdAR8DOAa3Pf0ZEQp meWufMVwSv8qZLTj/SWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGlxL-00000006RQq-0k5A; Mon, 10 Jun 2024 20:49:31 +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 1sGlwo-00000006R3l-3MWo for linux-arm-kernel@lists.infradead.org; Mon, 10 Jun 2024 20:49:00 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1F7F160C3E; Mon, 10 Jun 2024 20:48:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A8B8C2BBFC; Mon, 10 Jun 2024 20:48:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1718052537; bh=ZLKP+8SlFBbrksEeWgQE5JXZVIKp4sUqZEnPm1wWp08=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oW6YdVQZvb7pT3RZFzWwOH0DwmEzdPSEz6ug0yrQT5f7eFcIFPll+TIRF/JYMqYAN IPuGjDiAiCBVYcvtkSVVlzyLqnVfjT59DCr4d/zHaCDWs3pNa9EDzgXhxWifioijEi SB0wd1qaiCK27TsS/Cb+VMdqMj9GjYqEaSE5JufY= From: Linus Torvalds To: Peter Anvin , Ingo Molnar , Borislav Petkov , Thomas Gleixner , Rasmus Villemoes , Josh Poimboeuf , Catalin Marinas , Will Deacon Cc: Linux Kernel Mailing List , the arch/x86 maintainers , linux-arm-kernel@lists.infradead.org, linux-arch , Linus Torvalds Subject: [PATCH 7/7] arm64: access_ok() optimization Date: Mon, 10 Jun 2024 13:48:21 -0700 Message-ID: <20240610204821.230388-8-torvalds@linux-foundation.org> X-Mailer: git-send-email 2.45.1.209.gc6f12300df In-Reply-To: <20240610204821.230388-1-torvalds@linux-foundation.org> References: <20240610204821.230388-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-20240610_134859_011737_6D8DC853 X-CRM114-Status: GOOD ( 20.46 ) 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 4ab3938290ab..a435eff4ee93 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