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 > > 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. :-) > 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 For reference, I've now tried building glibc with a bti-enabled gcc-12 and the following patch. The resulting build has functioning BTI. Thanks! diff -Nru glibc-2.37/debian/sysdeps/arm64.mk glibc-2.37/debian/sysdeps/arm64.mk --- glibc-2.37/debian/sysdeps/arm64.mk 2023-10-02 22:29:12.000000000 +0200 +++ glibc-2.37/debian/sysdeps/arm64.mk 2023-11-28 10:35:40.000000000 +0100 @@ -1,2 +1,5 @@ +HOST_CFLAGS += -mbranch-protection=standard +HOST_CXXFLAGS += -mbranch-protection=standard + # configuration options for all flavours -extra_config_options = --enable-multi-arch --enable-memory-tagging +extra_config_options = --enable-multi-arch --enable-memory-tagging CFLAGS=-mbranch-protection=standard
