Hi Emanuele, On 2023-12-04 16:13, Emanuele Rocca wrote: > Hello Aurelien, > > On 2023-12-03 01:08, Aurelien Jarno wrote: > > On 2023-11-29 09:56, Emanuele Rocca wrote: > > > To add BTI to the NOTE section of the above, we would need to build both > > > GCC and glibc with -mbranch-protection=standard. For gcc-13 I have > > > proposed https://bugs.debian.org/1055711. Given that glibc in Debian is > > > built with gcc-12, we will also need to build gcc-12 with > > > -mbranch-protection=standard. > > > > The plan is to switch to gcc-13 once we have glibc 2.38 in testing. I > > hope to be able to push glibc 2.38 to unstable in the next weeks. > > Nice! In any case, ideally we can get BTI enabled in both gcc-12 and > gcc-13, so that users of both versions can take advantage of the > feature. > > > > When it comes to glibc itself, there is a configure check to enable BTI > > > support [2], and it uses CFLAGS as passed to ./configure. I have done > > > the following here on my arm64 machine: > > > > > > - built gcc-12 with PAC/BTI (see #1055711) > > > - built glibc with the PAC/BTI enabled gcc-12 and the attached patch > > > Is it necessary to wait for gcc-12 to be fixed before doing the change > > on the glibc side? > > Yes, it is. Without gcc support, glibc would fail building due to the > use of -z force-bti when not all inputs have BTI in the NOTE section. > See: https://people.debian.org/~ema/glibc-no-gcc-bti_2.37-12.1_arm64.build
Ok, thanks for the confirmation. I give a try to provide a better patch and indeed ending up with this issue. > > > diff -Nru glibc-2.37/debian/rules.d/build.mk > > > glibc-2.37/debian/rules.d/build.mk > > > --- glibc-2.37/debian/rules.d/build.mk 2023-10-02 22:29:12.000000000 > > > +0200 > > > +++ glibc-2.37/debian/rules.d/build.mk 2023-11-28 10:35:40.000000000 > > > +0100 > > > @@ -97,6 +97,7 @@ > > > echo -n "Build started: " ; date --rfc-2822; \ > > > echo "---------------"; \ > > > cd $(DEB_BUILDDIR) && \ > > > + $(if $(filter -mbranch-protection=standard,$(shell > > > dpkg-buildflags --get CFLAGS)),CFLAGS=-mbranch-protection=standard) \ > > > > I don't get why this is necessary with the changes in debian/rules. > > glibc's configure script is using CFLAGS when running the check > "checking for BTI support", and I couldn't find any other way to get > that check to say "yes" other than passing CFLAGS to ./configure. Happy > to do it otherwise, if you can find working alternatives. :-) Understood, it looks like to me a bug in the configure script. Anyway please see the patch below as an alternative workaround. > > Also I am concerned with the use of dpkg-buildflags in the cross build > > context, given that feature is arm64 specific. Is there any drawback in > > enabling branch protection unconditionally? > > No, we just need to avoid passing the flag to non-aarch64 compilers when > cross-building. I understand that this is already taken care of if we > move the code to d/sysdeps/arm64.mk? For example, this would fail: > > x86_64-linux-gnu-gcc-13 -mbranch-protection=standard > > The type of error is the same as passing -fcf-protection to an aarch64 > gcc: > > aarch64-linux-gnu-gcc-13 -fcf-protection Ok, so i think it's better to enable BTI unconditionally for the arm64 glibc. > For reference, I've now tried building glibc with a bti-enabled gcc-12 > and the following patch. The resulting build has functioning BTI. What about the patch below, it basically just change the compiler to always enable -mbranch-protection=standard, and it's also used for the configure script. Regards Aurelien --- glibc-2.37/debian/sysdeps/arm64.mk +++ glibc-2.37/debian/sysdeps/arm64.mk @@ -1,2 +1,5 @@ # configuration options for all flavours extra_config_options = --enable-multi-arch --enable-memory-tagging + +CC = $(DEB_HOST_GNU_TYPE)-$(BASE_CC)$(DEB_GCC_VERSION) -mbranch-protection=standard +CXX = $(DEB_HOST_GNU_TYPE)-$(BASE_CXX)$(DEB_GCC_VERSION) -mbranch-protection=standard -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net