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 559FDC05027 for ; Wed, 8 Feb 2023 13:01:25 +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=VBE9ThOPP2q6gct1hpQ2t5tAWYdBXWKNeZL3igJLYEc=; b=mvhYDYgNTH4r5R FSOr4/kqYlrodupMvIT0DD7c8cbQSx4l18AyH4Lv3YIH4LKlimITF1VYzjjoaXVN7RLWfWuUQlBKQ RYzrRJFudS0TQDNKnKMIUXO7DbIFgWF8RE3CsbIKiSEhBaYZXgj4S76duWvDcxTmIFFpskqTdj07j vOqHOwQ9Vy+YpxRam5pdeaKTGu38zuDFSJ5vQ+Uf3CfVgFnPSbfy+MnWs8x78tjLXSOEe8vf8H7dz uiN8mkd+MiPW/GX5+FCmvN8uqakMNnUgR6eJ5v8NJ7BKKWBrFIfucIaxNDN9c+8F521qxUfVDwoUz 37HpHpWkKGeDlTQSn1qg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPk3e-00FgAA-Rx; Wed, 08 Feb 2023 13:00:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPk3b-00Fg94-KK for linux-arm-kernel@lists.infradead.org; Wed, 08 Feb 2023 13:00:16 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 5FC38616C9; Wed, 8 Feb 2023 13:00:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4DB7C433D2; Wed, 8 Feb 2023 13:00:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675861213; bh=i2wyhlZLGEJYBJUAHMF2WHs1gWfyCC+jbEx2HGxuu9k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n2z8RDLwCPHEVws1AqG9KxBnEqX4BXK47KA5yEkrkwTYiN53NaCM/G9GlrIRlp77G TB4XOVeVIqxDhHx9Zo9lN5WGLnvOkcPtvwTOdsOvYhyp0Dmh1DJ3KvBczT9SIpjZ0f PbqIK8B/mlo4SRU1Ua/QnmTUuRUQpNTN0VsO5WOYQgLNjA1sULlFl8g4EtMChjRg0N HYR9QadmddxcpprWFOjBHnM3+jq5MS0A4fK4zvnb8OBnWgcH/nKRiYqfAmdP1UEN3S XhrIwbI5bOUR69yqW8rybCez8noH2Pcule6lbkEXPnh1erLoBBpVw5LoAiCX15J9k0 WZScX38Nz4paQ== Date: Wed, 8 Feb 2023 13:00:08 +0000 From: Will Deacon To: Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas , Kees Cook , Mark Rutland , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen Subject: Re: [PATCH v2 2/3] efi: arm64: Wire up BTI annotation in memory attributes table Message-ID: <20230208130007.GA13529@willie-the-truck> References: <20230206124938.272988-1-ardb@kernel.org> <20230206124938.272988-3-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230206124938.272988-3-ardb@kernel.org> 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-20230208_050015_743534_46D8B849 X-CRM114-Status: GOOD ( 22.58 ) 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 Mon, Feb 06, 2023 at 01:49:37PM +0100, Ard Biesheuvel wrote: > UEFI v2.10 extends the EFI memory attributes table with a flag that > indicates whether or not all RuntimeServicesCode regions were > constructed with BTI landing pads, permitting the OS to map these > regions with BTI restrictions enabled. > > So let's take this into account on arm64. > > Signed-off-by: Ard Biesheuvel > Reviewed-by: Kees Cook > --- > arch/arm64/kernel/efi.c | 14 ++++++++++++-- > arch/arm64/kernel/traps.c | 6 ++++++ > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c > index 78ffd5aaddcbbaee..99971cd349f36310 100644 > --- a/arch/arm64/kernel/efi.c > +++ b/arch/arm64/kernel/efi.c > @@ -96,15 +96,23 @@ int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md) > return 0; > } > > +struct set_perm_data { > + const efi_memory_desc_t *md; > + bool has_bti; > +}; > + > static int __init set_permissions(pte_t *ptep, unsigned long addr, void *data) > { > - efi_memory_desc_t *md = data; > + struct set_perm_data *spd = data; > + const efi_memory_desc_t *md = spd->md; > pte_t pte = READ_ONCE(*ptep); > > if (md->attribute & EFI_MEMORY_RO) > pte = set_pte_bit(pte, __pgprot(PTE_RDONLY)); > if (md->attribute & EFI_MEMORY_XP) > pte = set_pte_bit(pte, __pgprot(PTE_PXN)); > + else if (system_supports_bti() && spd->has_bti) system_supports_bti() seems to check CONFIG_ARM64_BTI rather than CONFIG_ARM64_BTI_KERNEL. In theory, I think this means we could have mismatched BTI support, so it might be slightly more robust to use the latter option here even thought the runtime services aren't kernel code. What do you think? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel