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 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 E9CF0C54EE9 for ; Thu, 22 Sep 2022 20:56:55 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fMe6L4nNfGgcVItDgLEveVHXGcUUrO1PtQiY79X73Do=; b=XplgXPqnPfI+my Lcy7uuqMceNsLz2xFprS0d1iGcKMZCyR8lRTxGuBOS5gi3iFBRSzg0EP3od2QzRWjlnF96tvXFPBH JL3gh3ExGn9DecKAi7vW3HFHSNY1ENxrzgFJ+kw+ArBtywDEHqQZkf4abbNqMrAh9A0InC+XnhKdc lFvfHwqbj0SsILtr/EOBP9a6MNiGbWE0tFTRaF9Osz4NBSBw1sOgWsULyOGeFd6WYp0ZZM3IMJHEc h3jl+DC75oqZ6mpacRzy8NMm0CQwXxFXzDYTjGZHDMHp3w+WQ5YrvkPVuYXPdUVfPOOlWcxjo+mUC tnJuLrQr4wJGaWUZS0Rg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1obTEj-000CvT-Ch; Thu, 22 Sep 2022 20:55:57 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1obTEg-000Cug-2r for linux-arm-kernel@lists.infradead.org; Thu, 22 Sep 2022 20:55:55 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5F6AFB80A26; Thu, 22 Sep 2022 20:55:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0689FC433C1; Thu, 22 Sep 2022 20:55:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663880151; bh=v4FH2PgXAvXXzbXEaSOtnw7JPkJE3VqDTia+MmdY3Po=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QF3rW+6WNT6gLS5/ka90KDSpdZScl3nHtPPFQQkQwa/xLrB3xHMtl2efB7IQ/O7Yj yHIeZqOvxh4KRoxqkLCqSe/fF66/+CJgxjhPec6SmsIC4UeRuOAtfjp8WE4MTnHiyG xC84Sir3Iel5KAKaYSZa+7jkMWxx52XdjNRsqvKAWwcaYnCkuK5ADxbbyxkyd4y3ju qj6H6n7roH5nyd0p0miYSzsVqV+smhIBZK9OLlAY6l+NKfr4z5gtn6iqn5zbU6JfP1 hEIcmJMDZ2AFPEBYAgJrYrrZ+TXY508MeW+EyeQ2PwFVTbjUNtEwJ452PK/yahrafO zubLh8FM0BFFw== Date: Thu, 22 Sep 2022 21:55:46 +0100 From: Will Deacon To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, james.morse@arm.com, robin.murphy@arm.com Subject: Re: [PATCH] arm64: uaccess: simplify uaccess_mask_ptr() Message-ID: <20220922205545.GA12945@willie-the-truck> References: <20220922151053.3520750-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220922151053.3520750-1-mark.rutland@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220922_135554_442891_72ACAE57 X-CRM114-Status: GOOD ( 34.00 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Sep 22, 2022 at 04:10:53PM +0100, Mark Rutland wrote: > We introduced uaccess pointer masking for arm64 in commit: > > 4d8efc2d5ee4c9cc ("arm64: Use pointer masking to limit uaccess speculation") > > Which was intended to prevent speculative uaccesses to kernel memory on > CPUs where access permissions were not respected under speculation. > > At the time, the uaccess primitives were occasionally used to access > kernel memory, with the maximum permitted address held in > thread_info::addr_limit. Consequently, the address masking needed to > take this dynamic limit into account. > > Subsequently the uaccess primitives were reworked such that they are > only used for user memory, and as of commit: > > 3d2403fd10a1dbb3 ("arm64: uaccess: remove set_fs()") > > ... the address limit was made a compile-time constant, but the logic > was otherwise unchanged. > > Regardless of the configured VA size or whether TBI is in use, the > address space can be divided into three ranges: > > * The TTBR0 VA range, for which any valid pointer has bit 55 *clear*, > and any non-tag bits [63-56] must match bit 55 (i.e. must be clear). > > * The TTBR1 VA range, for which any valid pointer has bit 55 *set*, and > any non-tag bits [63-56] must match bit 55 (i.e. must be set). > > * The gap between the TTBR0 and TTBR1 ranges, where bit 55 may be set or > clear, but any access will result in a fault. > > As the uaccess primitives are now only used for user memory in the TTBR0 > VA range, we can prevent generation of TTBR1 addresses by clearing bit > 55, which will either result in a TTBR0 address or a faulting address > between the TTBR VA ranges. > > This is beneficial for code generation as: > > * We no longer clobber the condition codes. > > * We no longer burn a register on (TASK_SIZE_MAX - 1). > > * We no longer need to consume the untagged pointer. > > When building a defconfig v6.0-rc3 with GCC 12.1.0, this change makes > the resulting Image 64KiB smaller. > > Signed-off-by: Mark Rutland > Cc: Catalin Marinas > Cc: James Morse > Cc: Robin Murphy > Cc: Will Deacon > --- > arch/arm64/include/asm/uaccess.h | 19 ++++++++++--------- > 1 file changed, 10 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h > index 2fc9f0861769a..e69559826cb8c 100644 > --- a/arch/arm64/include/asm/uaccess.h > +++ b/arch/arm64/include/asm/uaccess.h > @@ -203,9 +203,11 @@ static inline void uaccess_enable_privileged(void) > } > > /* > - * Sanitise a uaccess pointer such that it becomes NULL if above the maximum > - * user address. In case the pointer is tagged (has the top byte set), untag > - * the pointer before checking. > + * Sanitize a uaccess pointer such that it cannot reach any kernel address. > + * > + * Clearing bit 55 ensures the pointer cannot address any portion of the TTBR1 > + * address range (i.e. any kernel address), and either the pointer falls within > + * the TTBR0 address range or must cause a fault. > */ > #define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr) > static inline void __user *__uaccess_mask_ptr(const void __user *ptr) > @@ -213,12 +215,11 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr) > void __user *safe_ptr; > > asm volatile( > - " bics xzr, %3, %2\n" > - " csel %0, %1, xzr, eq\n" > - : "=&r" (safe_ptr) > - : "r" (ptr), "r" (TASK_SIZE_MAX - 1), > - "r" (untagged_addr(ptr)) > - : "cc"); > + " bic %0, %1, %2\n" > + : "=r" (safe_ptr) > + : "r" (ptr), > + "i" (BIT(55)) > + ); > > csdb(); Why do we still need the CSDB after your change? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel