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.34616.1679922982243998357 for ; Mon, 27 Mar 2023 06:16:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gAfbbeVg; 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 8EC476126A for ; Mon, 27 Mar 2023 13:16:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84DD4C4339E for ; Mon, 27 Mar 2023 13:16:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679922980; bh=vCmthat2rycIsv0eHJg/wK2WKalFcElwiXfKn/Mn7xU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gAfbbeVgJWvvW98rIO2dg+BrQ7T9fjIjEOuCV0XY2bqkEn3LdOa18LVDXNsOxLUEY R79On6EPtAp4dzE/W0Z+Ng8ycWaNfECIMIS/oC5y17iPyjWbkryEOWyTd3x1EIYQfK UcTKMOgCRimAmwop9dydaMiwT+IaELaXydifOGs+0t3ydprAr9U1fl7kkDprqUuSPL 1gmFSpAo4rRDF5su2EJYhP/9uvQeNLxzdOgIRhNYtIDnbWbKDTAf8NgtqLr9EIH8mA g5J91IXfwGbxtPKRWuho6N8DkCEZNSpKk3PLK2Ne+2YuVMPRvNIQyg3JTnjafS+OKC i+v5qTPPYSg+Q== Received: by mail-lj1-f176.google.com with SMTP id e21so8975925ljn.7 for ; Mon, 27 Mar 2023 06:16:20 -0700 (PDT) X-Gm-Message-State: AAQBX9cCpdICLDShmIJ2BbYRwD7qY9B+uV/YeltmLBKgFiJlHOYgwjtn w9IZlMpcY4P6/ZLuD36evLve0yp7ah3r4HRYnRo= X-Google-Smtp-Source: AKy350Zks1R0WYR9TMhLxP9CBq7hcI7/l+8u6gmcT/n2NKvtk+7NZ9zjvoOwYjumr+hFk3EEMEpI5zUHEIRZMdCz68I= X-Received: by 2002:a2e:9c0f:0:b0:299:ac5e:376e with SMTP id s15-20020a2e9c0f000000b00299ac5e376emr3464831lji.2.1679922978391; Mon, 27 Mar 2023 06:16:18 -0700 (PDT) MIME-Version: 1.0 References: <20230327110112.262503-1-ardb@kernel.org> <20230327110112.262503-12-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 27 Mar 2023 15:16:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v2 11/17] ArmPkg, BaseTools AARCH64: Add BTI ELF note to .hii objects To: devel@edk2.groups.io, quic_llindhol@quicinc.com Cc: Michael Kinney , Liming Gao , Jiewen Yao , Michael Kubacki , Sean Brogan , Rebecca Cran , Sami Mujawar , Taylor Beebe , =?UTF-8?Q?Marvin_H=C3=A4user?= , Bob Feng Content-Type: text/plain; charset="UTF-8" On Mon, 27 Mar 2023 at 15:10, Leif Lindholm wrote: > > On Mon, Mar 27, 2023 at 13:01:06 +0200, Ard Biesheuvel wrote: > > The ELF based toolchains use objcopy to create HII object files, which > > contain only a single .hii section. This means no GNU note is inserted > > that describes the object as compatible with BTI, even though the lack > > of executable code in such an object makes the distinction irrelevant. > > However, the linker will not add the note globally to the resulting ELF > > executable, and this breaks BTI compatibility. > > > > So let's insert a GNU BTI-compatible ELF note by hand when generating > > such object files. > > > > Signed-off-by: Ard Biesheuvel > > --- > > ArmPkg/Library/GnuNoteBti.bin | Bin 0 -> 32 bytes > > BaseTools/Conf/tools_def.template | 4 ++-- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/ArmPkg/Library/GnuNoteBti.bin b/ArmPkg/Library/GnuNoteBti.bin > > new file mode 100644 > > index 0000000000000000000000000000000000000000..339567b4e89943c610b44767ddad5f631229ed3b > > GIT binary patch > > literal 32 > > dcmZQ!U| > > > literal 0 > > HcmV?d00001 > > > > diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template > > index 471eb67c0c839730..ed6050aa96157cb9 100755 > > --- a/BaseTools/Conf/tools_def.template > > +++ b/BaseTools/Conf/tools_def.template > > @@ -2400,7 +2400,7 @@ RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS > > *_GCC5_AARCH64_DTCPP_FLAGS = DEF(GCC_DTCPP_FLAGS) > > *_GCC5_AARCH64_PLATFORM_FLAGS = > > *_GCC5_AARCH64_PP_FLAGS = $(PLATFORM_FLAGS) DEF(GCC_PP_FLAGS) > > -*_GCC5_AARCH64_RC_FLAGS = DEF(GCC_AARCH64_RC_FLAGS) > > +*_GCC5_AARCH64_RC_FLAGS = DEF(GCC_AARCH64_RC_FLAGS) --add-section .note.gnu.property=$(WORKSPACE)/ArmPkg/Library/GnuNoteBti.bin --set-section-flags .note.gnu.property=alloc,readonly > > *_GCC5_AARCH64_VFRPP_FLAGS = $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) > > *_GCC5_AARCH64_CC_XIPFLAGS = DEF(GCC5_AARCH64_CC_XIPFLAGS) > > > > @@ -2735,7 +2735,7 @@ DEFINE CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_TARGET) DEF(GCC_AARCH6 > > *_CLANG38_AARCH64_DLINK2_FLAGS = DEF(GCC_DLINK2_FLAGS_COMMON) -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 > > *_CLANG38_AARCH64_PLATFORM_FLAGS = > > *_CLANG38_AARCH64_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_AARCH64_TARGET) $(PLATFORM_FLAGS) > > -*_CLANG38_AARCH64_RC_FLAGS = DEF(GCC_AARCH64_RC_FLAGS) > > +*_CLANG38_AARCH64_RC_FLAGS = DEF(GCC_AARCH64_RC_FLAGS) --add-section .note.gnu.property=$(WORKSPACE)/ArmPkg/Library/GnuNoteBti.bin --set-section-flags .note.gnu.property=alloc,readonly > > Bikeshedding, but could we have an AARCH64_BTI_RC_FLAGS or something > set, which is expanded for each toolchain profile? I think this is > esoteric enough that it's helpful to group just the > bti-note-incantations together in a single place. > Sure. It's a bit disappointing that we even need this - the linker should be able to infer that for objects without any executable sections, whether the note exists or not is irrelevant.