Re: Enabling PAC/BTI support on arm64
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
aurelien@aurel32.net http://aurel32.net
Reply to: