From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.34090.1679921706795253224 for ; Mon, 27 Mar 2023 05:55:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=huQ6UlQd; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) 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 500176122C for ; Mon, 27 Mar 2023 12:55:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 353C0C433A1 for ; Mon, 27 Mar 2023 12:55:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679921705; bh=9u4SRJnvtvNYKPb8D/9Ai5j9KkRLMy7EPVVxEtawQ4o=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=huQ6UlQdmtoDEijVtCDx1gRmjabqu/MFmm2/AqUx5vfEfs9heWcVdq1F0ehUbNVDb c5BypG1lWCLtCViBzhjvnKoPZb43PaaV/zgnN0AtsVUBcqQ7NMyyUO31BwCIfPDwE9 jVf673PERYPtd7lNIr2ulTG3QGdP4OeM86w8CwSh7cWzYlMbskrf4X1ITJ0J3MZ4cw 5VOLu2in0f7ClSgnqH6778hCDAdA5JmUuFm/20D4bVGBTVerote9p4jG8Pr0bmCOmu V7+pVhE74wz5by/V8ctmK0arkY3BT70AHQ1xZLowcE+uNGPFlDfUQ9mmu0pL3Wh1bq V24PIW4khC3vQ== Received: by mail-lj1-f180.google.com with SMTP id 20so8933486lju.0 for ; Mon, 27 Mar 2023 05:55:05 -0700 (PDT) X-Gm-Message-State: AAQBX9fgPPi0H9h41R5OUItD8dHzskRFUEEkWBsft7kzKrWNUFphuIW0 z+kw7FDbM2sdeEbMrJUz5rQ/9IzcyXimRz0bWVA= X-Google-Smtp-Source: AKy350bFa3eu9WTfgj3PIErGINjj/rEMEvaZHCaMYiHlsCTftdu+b/s5snKW9eRmjj187inhmJMLFLhre+BSbNV6ulQ= X-Received: by 2002:a2e:9c11:0:b0:298:bddc:dbbf with SMTP id s17-20020a2e9c11000000b00298bddcdbbfmr3438805lji.2.1679921703190; Mon, 27 Mar 2023 05:55:03 -0700 (PDT) MIME-Version: 1.0 References: <20230327110112.262503-1-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 27 Mar 2023 14:54:52 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v2 00/17] Enable BTI support in memory attributes table To: devel@edk2.groups.io, quic_llindhol@quicinc.com, Rebecca Cran Cc: Michael Kinney , Liming Gao , Jiewen Yao , Michael Kubacki , Sean Brogan , Sami Mujawar , Taylor Beebe , =?UTF-8?Q?Marvin_H=C3=A4user?= , Bob Feng Content-Type: text/plain; charset="UTF-8" (update Rebecca's email) On Mon, 27 Mar 2023 at 13:43, Leif Lindholm wrote: > > On Mon, Mar 27, 2023 at 13:00:55 +0200, Ard Biesheuvel wrote: > > Implement version 2 of the memory attributes table, which now contains a > > flag informing the OS whether or not code regions may be mapped with CFI > > mitigations such as IBT or BTI enabled. > > > > This series covers roughly the following parts: > > > > - (AARCH64) Annotate ELF objects generated from asm as BTI compatible > > when BTI codegen is enabled > > - Update the BaseTools to emit the appropriate PE/COFF annotation when a > > BTI/IBT compatible ELF executable is converted to PE/COFF > > - Take this PE/COFF annotation into account when populating the memory > > attributes table in the DXE core > > > > TODO: > > - X64 changes to make the code IBT compatible and emit the ELF note > > - Figure out how to generate such executables with native PE toolchains > > - Implement BTI/IBT enforcement at boot time - this is something I > > intend to look into next. > > > > Can be tested with the CLANG38 toolchain (both Clang compiler and LLD > > linker, version 3.8 or newer) with the following build options. > > > > [BuildOptions] > > GCC:*_*_AARCH64_PP_FLAGS = -mbranch-protection=bti > > GCC:*_*_AARCH64_CC_FLAGS = -mbranch-protection=bti > > I know you point out to use CLANG38, but the set is also tagged PATCH > rather than RFC. > I believe this option was added to GCC in version 9, meaning this is a > breaking change for GCC8. Now, GCC8 is ancient, but I expect it's > still what's available in RHEL8 for example. So it's worth mentioning. > Indeed. So when and where to enable this (by default or not) is an open question. I thought we might enable this by default for CLANGDWARF once we add AArch64 support to it (which Rebecca is working on), and retire the CLANG3x toolchains entirely. Then, it is up to individual platforms to decide what they want to enable or disable - it also depends on any asm code the platforms are carrying. (This does not really matter for this series which only covers runtime DXE executables running under the OS, but i'd like to find ways to enable this at boot time as well)