Message ID | 20230807-arm64-gcs-v4-9-68cfa37f9069@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp1755066vqr; Mon, 7 Aug 2023 15:52:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHVmw2tuipnbQDg4TQzs2BGBktM3C9lfu8LMHWmqr6zstlOnxcLY3ftg4AjmR5GByuvKaCb X-Received: by 2002:a17:902:d2c4:b0:1bb:994c:bc43 with SMTP id n4-20020a170902d2c400b001bb994cbc43mr11528061plc.18.1691448722252; Mon, 07 Aug 2023 15:52:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691448722; cv=none; d=google.com; s=arc-20160816; b=E4oki/wnquI1vBAoOfMmPmCSEzN4CZ6poEDN9Fpwg6KJFdBmNPJR9V2q4GP7FAd1qm Wuv9f7RJtPATusR5dtMg7MI1i8Xx3PoXBw2dRF5DSepR/xrRL8aPvsT7NkofWWzCV7wd Q1mEP+ZJPzYQR6ojBA2dtaLkRPmihhfjNUefZNgNoEhNuizQaNU2PehjyZrNF7ET3xIW ZcvUHeAlsr+rv9l2x2JbXPN7f331gWlYxlv0v7ZAHq7jo3Md2S48eDwnXY/8Pega1YAk AQbL8BVCrkKzYlej04GbjhnJzH08DxTy+UUXNnLdxRLVFWQlBOFSn9jjLe044BeiZ4vs auCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=Dnc2nP1HVaiEDoBVg12zB7TbohL1GVCNMw7SaItQG9I=; fh=EdAFSmIgUzZTC6WCy4Jg1wBZ0/m6m2d/OjiRUJ3BsTI=; b=G6Ig7DYhR8tX1ko5l3qI848UZZasDepCry4w+5t9u94DLLoX3+EK7GJi1cRwcL9M13 TkS4g9wVrgCXa6ademN4TVUG3oN4Wa0sP95Y4bP0Y1eet+hlmsFFzl4zRmC+MDVT2qum X659pWKFX5D5fqx/hCUDMpQU2HFdFo/Xx/FGzOefOtme2Runra+IX6MMifV7CtW/bJYb 0E7JEl10J/ogUt8VJFeGzeXuzxm/u2uogTH2Eas19lmhF8T8Nv/pvrmAW3D7GNJ0zqrD bDYlE/brMoDDDNyVQ596gCeVcwBd9YzhxCivlZ0q5OEitLWe4RuIcN6hZpNOc2DquLlf NVoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EmOZ2tYU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kp15-20020a170903280f00b001b9ffda162csi4546704plb.441.2023.08.07.15.51.49; Mon, 07 Aug 2023 15:52:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EmOZ2tYU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229498AbjHGWDg (ORCPT <rfc822;aaronkmseo@gmail.com> + 99 others); Mon, 7 Aug 2023 18:03:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231236AbjHGWC6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 7 Aug 2023 18:02:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2C992136; Mon, 7 Aug 2023 15:02:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AEDDF622A3; Mon, 7 Aug 2023 22:02:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61D44C433B6; Mon, 7 Aug 2023 22:02:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691445747; bh=BgZhQzy1ZDJ87SbUj0QMsK2M0tcAHYl7N7+4HCzYWRs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=EmOZ2tYUJCJhMhJ7hO34qV5fLR5s6c+Swyx0MdJ40FErxgl5j1pJ1C/4mPxfC/fB0 zDT+DR54Mvr4RmVYj3PS0INYq5at6DJwiJvlBLToBENbgbSF9qThUiahmn/iImdMun PbRfcsONPOAz/DgAjZkxiEiueS6TUZ5Yi6L6FvhGBVc1jkT4KNRf3lkY+HfN1hSh2D VFR2AVLEomJrR2LGmXga00ZjV0tf0hkN6eRbDVRD4D3G41ruz+/5U7xBTi7fc6s7L4 8rXROIj6mbaHHv12TMfkAL0zqssrdoHVk7BA+B8lqyVX07XUu8TZWdW8z9DNOBAnTQ 2mlgvyFVXCLDQ== From: Mark Brown <broonie@kernel.org> Date: Mon, 07 Aug 2023 23:00:14 +0100 Subject: [PATCH v4 09/36] arm64/mm: Allocate PIE slots for EL0 guarded control stack MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230807-arm64-gcs-v4-9-68cfa37f9069@kernel.org> References: <20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org> In-Reply-To: <20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>, Andrew Morton <akpm@linux-foundation.org>, Marc Zyngier <maz@kernel.org>, Oliver Upton <oliver.upton@linux.dev>, James Morse <james.morse@arm.com>, Suzuki K Poulose <suzuki.poulose@arm.com>, Arnd Bergmann <arnd@arndb.de>, Oleg Nesterov <oleg@redhat.com>, Eric Biederman <ebiederm@xmission.com>, Kees Cook <keescook@chromium.org>, Shuah Khan <shuah@kernel.org>, "Rick P. Edgecombe" <rick.p.edgecombe@intel.com>, Deepak Gupta <debug@rivosinc.com>, Ard Biesheuvel <ardb@kernel.org>, Szabolcs Nagy <Szabolcs.Nagy@arm.com> Cc: "H.J. Lu" <hjl.tools@gmail.com>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Mark Brown <broonie@kernel.org> X-Mailer: b4 0.13-dev-034f2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2919; i=broonie@kernel.org; h=from:subject:message-id; bh=BgZhQzy1ZDJ87SbUj0QMsK2M0tcAHYl7N7+4HCzYWRs=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBk0WmfSCjgX4zgvM1dX0NE3FBZc7yto4Ja/r7dY9ZP YJvd+7mJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZNFpnwAKCRAk1otyXVSH0LkeB/ 487t0CeDsRzEJ/l8PbvmVhXGzZVKGNciRrG6v29QenKmFmWK3ROkp6BzL/Dr4xPkYV9tDVG69jz2aW noHAWdge6E/0geaaJAFe05seIm9jrY46BFHIZxolVLKZH4oFO0uG3qyA+Ct9k2m2RQI+zLhSAIj2Ue aO41sp2HhKo8umHeqzwsPEdHCZIlmQUPrK3X5emQgDFo/6iYIl7t2GRErkfDQdNq6kI+7i78vRgwHs M1fyR9/182RGa2FTE6YB6iQZY9Jpp1ngitVNFnpgQz7Gn9UTy5WHOU9xWttf7pOQFH7FZ3OIQ7BGRe w9VbzxIICBHqJFtASettRlZBpIAvmI X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773612535359100717 X-GMAIL-MSGID: 1773612535359100717 |
Series |
arm64/gcs: Provide support for GCS in userspace
|
|
Commit Message
Mark Brown
Aug. 7, 2023, 10 p.m. UTC
Pages used for guarded control stacks need to be described to the hardware
using the Permission Indirection Extension, GCS is not supported without
PIE. In order to support copy on write for guarded stacks we allocate two
values, one for active GCSs and one for GCS pages marked as read only prior
to copy.
Since the actual effect is defined using PIE the specific bit pattern used
does not matter to the hardware but we choose two values which differ only
in PTE_WRITE in order to help share code with non-PIE cases.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/include/asm/pgtable-prot.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
Comments
On Mon, Aug 07, 2023 at 11:00:14PM +0100, Mark Brown wrote: > diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h > index eed814b00a38..b157ae0420ed 100644 > --- a/arch/arm64/include/asm/pgtable-prot.h > +++ b/arch/arm64/include/asm/pgtable-prot.h > @@ -131,15 +131,23 @@ extern bool arm64_use_ng_mappings; > /* 6: PTE_PXN | PTE_WRITE */ > /* 7: PAGE_SHARED_EXEC PTE_PXN | PTE_WRITE | PTE_USER */ > /* 8: PAGE_KERNEL_ROX PTE_UXN */ > -/* 9: PTE_UXN | PTE_USER */ > +/* 9: PAGE_GCS_RO PTE_UXN | PTE_USER */ > /* a: PAGE_KERNEL_EXEC PTE_UXN | PTE_WRITE */ > -/* b: PTE_UXN | PTE_WRITE | PTE_USER */ > +/* b: PAGE_GCS PTE_UXN | PTE_WRITE | PTE_USER */ > /* c: PAGE_KERNEL_RO PTE_UXN | PTE_PXN */ > /* d: PAGE_READONLY PTE_UXN | PTE_PXN | PTE_USER */ > /* e: PAGE_KERNEL PTE_UXN | PTE_PXN | PTE_WRITE */ > /* f: PAGE_SHARED PTE_UXN | PTE_PXN | PTE_WRITE | PTE_USER */ > > +#define _PAGE_GCS (_PAGE_DEFAULT | PTE_UXN | PTE_WRITE | PTE_USER) > +#define _PAGE_GCS_RO (_PAGE_DEFAULT | PTE_UXN | PTE_USER) > + > +#define PAGE_GCS __pgprot(_PAGE_GCS) > +#define PAGE_GCS_RO __pgprot(_PAGE_GCS_RO) > + > #define PIE_E0 ( \ > + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS), PIE_GCS) | \ > + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO), PIE_R) | \ > PIRx_ELx_PERM(pte_pi_index(_PAGE_EXECONLY), PIE_X_O) | \ > PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY_EXEC), PIE_RX) | \ > PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED_EXEC), PIE_RWX) | \ > @@ -147,6 +155,8 @@ extern bool arm64_use_ng_mappings; > PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED), PIE_RW)) > > #define PIE_E1 ( \ > + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS), PIE_RW) | \ > + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO), PIE_R) | \ Had some thoughts on this. Why do we need the EL1 GCS attributes to map to RW? The instructions we'd use to write the shadow stack are the GCS 'T' variants that run as user already. The only instructions we have in the kernel that would run as EL1 on a user address are the exclusives (futex code or the old deprecated emulation but we don't care about them in this context). So I wonder whether the kernel PIE entry could simply be PIE_NONE_O. Would this be too restrictive for future uses? Given the coherency between a GCS access and a standard data access, we may want to restrict it now until we have a use-case.
On Fri, Aug 11, 2023 at 03:23:12PM +0100, Catalin Marinas wrote: > > #define PIE_E1 ( \ > > + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS), PIE_RW) | \ > > + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO), PIE_R) | \ > Had some thoughts on this. Why do we need the EL1 GCS attributes to map > to RW? The instructions we'd use to write the shadow stack are the GCS > 'T' variants that run as user already. > The only instructions we have in the kernel that would run as EL1 on a > user address are the exclusives (futex code or the old deprecated > emulation but we don't care about them in this context). So I wonder > whether the kernel PIE entry could simply be PIE_NONE_O. Would this be > too restrictive for future uses? Given the coherency between a GCS > access and a standard data access, we may want to restrict it now until > we have a use-case. Good point. I remember I originally wrote that before I checked into how things like copying pages for ptrace worked but they don't keep the GCSness of the page so they're fine. I don't think we need to worry about future uses since these are slots reserved for GCS use, if we need a different value later
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h index eed814b00a38..b157ae0420ed 100644 --- a/arch/arm64/include/asm/pgtable-prot.h +++ b/arch/arm64/include/asm/pgtable-prot.h @@ -131,15 +131,23 @@ extern bool arm64_use_ng_mappings; /* 6: PTE_PXN | PTE_WRITE */ /* 7: PAGE_SHARED_EXEC PTE_PXN | PTE_WRITE | PTE_USER */ /* 8: PAGE_KERNEL_ROX PTE_UXN */ -/* 9: PTE_UXN | PTE_USER */ +/* 9: PAGE_GCS_RO PTE_UXN | PTE_USER */ /* a: PAGE_KERNEL_EXEC PTE_UXN | PTE_WRITE */ -/* b: PTE_UXN | PTE_WRITE | PTE_USER */ +/* b: PAGE_GCS PTE_UXN | PTE_WRITE | PTE_USER */ /* c: PAGE_KERNEL_RO PTE_UXN | PTE_PXN */ /* d: PAGE_READONLY PTE_UXN | PTE_PXN | PTE_USER */ /* e: PAGE_KERNEL PTE_UXN | PTE_PXN | PTE_WRITE */ /* f: PAGE_SHARED PTE_UXN | PTE_PXN | PTE_WRITE | PTE_USER */ +#define _PAGE_GCS (_PAGE_DEFAULT | PTE_UXN | PTE_WRITE | PTE_USER) +#define _PAGE_GCS_RO (_PAGE_DEFAULT | PTE_UXN | PTE_USER) + +#define PAGE_GCS __pgprot(_PAGE_GCS) +#define PAGE_GCS_RO __pgprot(_PAGE_GCS_RO) + #define PIE_E0 ( \ + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS), PIE_GCS) | \ + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO), PIE_R) | \ PIRx_ELx_PERM(pte_pi_index(_PAGE_EXECONLY), PIE_X_O) | \ PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY_EXEC), PIE_RX) | \ PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED_EXEC), PIE_RWX) | \ @@ -147,6 +155,8 @@ extern bool arm64_use_ng_mappings; PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED), PIE_RW)) #define PIE_E1 ( \ + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS), PIE_RW) | \ + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO), PIE_R) | \ PIRx_ELx_PERM(pte_pi_index(_PAGE_EXECONLY), PIE_NONE_O) | \ PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY_EXEC), PIE_R) | \ PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED_EXEC), PIE_RW) | \