Hi Emanuele, On 2023-11-29 09:56, Emanuele Rocca wrote: > Hi! > > I would like to ask for suggestions about the best way to enable PAC/BTI > support in glibc and GCC on Debian. > > PAC and BTI are two useful Arm security features, see this recent > presentation at the Mini Debconf for all details: [0] > > In order to properly support PAC/BTI in Debian we need to enable support > in both GCC and glibc. An executable is marked as BTI compatible only if > all the execution units of the program are BTI compatible. See pages > 10-11 on the presentation slides. [1] > > One can easily verify if things work fine by building a test program as > follows: > > gcc -mbranch-protection=standard -z force-bti /tmp/test.c > > On systems where both GCC and glibc support PAC/BTI, the command above > returns no output, and the resulting executable has "BTI, PAC" listed in > the output of readelf -n: > > readelf -n a.out | grep Properties > Properties: AArch64 feature: BTI, PAC > > If PAC/BTI support is not enabled in GCC/glibc, building the program > with -z force-bti returns something like: > > /usr/bin/ld: > /usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/Scrt1.o: > warning: BTI turned on by -z force-bti when all inputs do not have BTI in > NOTE section. > /usr/bin/ld: > /usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/crti.o: warning: > BTI turned on by -z force-bti when all inputs do not have BTI in NOTE section. > /usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/13/crtbeginS.o: warning: BTI > turned on by -z force-bti when all inputs do not have BTI in NOTE section. > /usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/13/crtendS.o: warning: BTI > turned on by -z force-bti when all inputs do not have BTI in NOTE section. > /usr/bin/ld: > /usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/crtn.o: warning: > BTI turned on by -z force-bti when all inputs do not have BTI in NOTE section. > > 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. > 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 I have some comments about this patch (see below), but once I understand it, I do no see any issue to enable this feature on the glibc side, and I can propose a patch. Is it necessary to wait for gcc-12 to be fixed before doing the change on the glibc side? > diff -Nru glibc-2.37/debian/rules glibc-2.37/debian/rules > --- glibc-2.37/debian/rules 2023-10-02 22:29:12.000000000 +0200 > +++ glibc-2.37/debian/rules 2023-11-28 10:35:40.000000000 +0100 > @@ -112,6 +112,11 @@ > BUILD_CFLAGS = -O2 -g -fdebug-prefix-map=$(CURDIR)=. > HOST_CFLAGS = -pipe -O2 -g -fdebug-prefix-map=$(CURDIR)=. $(call > xx,extra_cflags) > > +ifeq ($(DEB_BUILD_ARCH),arm64) > + HOST_CFLAGS += -mbranch-protection=standard > + HOST_CXXFLAGS += -mbranch-protection=standard > +endif Given this change is arm64 specific, it would be better to move it to debian/sysdeps/arm64.mk instead. > 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. Also here the branch protection is enabled depending on dpkg-buildflags while in the debian/rules change, this is done unconditionally. Any reason for that? 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? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
