| Message ID | 20220511172129.2078337-1-andre.przywara@arm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d7a49291d786b4400996afe3afcc3ef5eeb6f0ef |
| Headers | show |
| Series | kselftest/arm64: bti: force static linking | expand |
On Wed, May 11, 2022 at 06:21:29PM +0100, Andre Przywara wrote: > The "bti" selftests are built with -nostdlib, which apparently > automatically creates a statically linked binary, which is what we want > and need for BTI (to avoid interactions with the dynamic linker). Reviewed-by: Mark Brown <broonie@kernel.org>
On Wed, May 11, 2022 at 06:21:29PM +0100, Andre Przywara wrote: > The "bti" selftests are built with -nostdlib, which apparently > automatically creates a statically linked binary, which is what we want > and need for BTI (to avoid interactions with the dynamic linker). > > However this is not true when building a PIE binary, which some > toolchains (Ubuntu) configure as the default. > When compiling btitest with such a toolchain, it will create a > dynamically linked binary, which will probably fail some tests, as the > dynamic linker might not support BTI: > =================== > TAP version 13 > 1..18 > not ok 1 nohint_func/call_using_br_x0 > not ok 2 nohint_func/call_using_br_x16 > not ok 3 nohint_func/call_using_blr > .... > =================== > > To make sure we create static binaries, add an explicit -static on the > linker command line. This forces static linking even if the toolchain > defaults to PIE builds, and fixes btitest runs on BTI enabled machines. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> Does this need to go in as a fix (cc stable, fixes tag)?
On Sun, 15 May 2022 11:05:23 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote: Hi, > On Wed, May 11, 2022 at 06:21:29PM +0100, Andre Przywara wrote: > > The "bti" selftests are built with -nostdlib, which apparently > > automatically creates a statically linked binary, which is what we want > > and need for BTI (to avoid interactions with the dynamic linker). > > > > However this is not true when building a PIE binary, which some > > toolchains (Ubuntu) configure as the default. > > When compiling btitest with such a toolchain, it will create a > > dynamically linked binary, which will probably fail some tests, as the > > dynamic linker might not support BTI: > > =================== > > TAP version 13 > > 1..18 > > not ok 1 nohint_func/call_using_br_x0 > > not ok 2 nohint_func/call_using_br_x16 > > not ok 3 nohint_func/call_using_blr > > .... > > =================== > > > > To make sure we create static binaries, add an explicit -static on the > > linker command line. This forces static linking even if the toolchain > > defaults to PIE builds, and fixes btitest runs on BTI enabled machines. > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > > Does this need to go in as a fix (cc stable, fixes tag)? I dimly remember some discussion about stable fixes not being a real thing for the selftests? In any case: Fixes: 314bcbf09f14 ("kselftest: arm64: Add BTI tests") Cheers, Andre
On Mon, May 16, 2022 at 10:29:35AM +0100, Andre Przywara wrote: > On Sun, 15 May 2022 11:05:23 +0100 > Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Wed, May 11, 2022 at 06:21:29PM +0100, Andre Przywara wrote: > > > The "bti" selftests are built with -nostdlib, which apparently > > > automatically creates a statically linked binary, which is what we want > > > and need for BTI (to avoid interactions with the dynamic linker). > > > > > > However this is not true when building a PIE binary, which some > > > toolchains (Ubuntu) configure as the default. > > > When compiling btitest with such a toolchain, it will create a > > > dynamically linked binary, which will probably fail some tests, as the > > > dynamic linker might not support BTI: > > > =================== > > > TAP version 13 > > > 1..18 > > > not ok 1 nohint_func/call_using_br_x0 > > > not ok 2 nohint_func/call_using_br_x16 > > > not ok 3 nohint_func/call_using_blr > > > .... > > > =================== > > > > > > To make sure we create static binaries, add an explicit -static on the > > > linker command line. This forces static linking even if the toolchain > > > defaults to PIE builds, and fixes btitest runs on BTI enabled machines. > > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > > > > Does this need to go in as a fix (cc stable, fixes tag)? > > I dimly remember some discussion about stable fixes not being a real thing > for the selftests? In any case: > > Fixes: 314bcbf09f14 ("kselftest: arm64: Add BTI tests") I'll add the fixes tag. I can see the occasional cc stable for kselftest patches.
On Wed, 11 May 2022 18:21:29 +0100, Andre Przywara wrote: > The "bti" selftests are built with -nostdlib, which apparently > automatically creates a statically linked binary, which is what we want > and need for BTI (to avoid interactions with the dynamic linker). > > However this is not true when building a PIE binary, which some > toolchains (Ubuntu) configure as the default. > When compiling btitest with such a toolchain, it will create a > dynamically linked binary, which will probably fail some tests, as the > dynamic linker might not support BTI: > =================== > TAP version 13 > 1..18 > not ok 1 nohint_func/call_using_br_x0 > not ok 2 nohint_func/call_using_br_x16 > not ok 3 nohint_func/call_using_blr > .... > =================== > > [...] Applied to arm64 (for-next/kselftest), thanks! [1/1] kselftest/arm64: bti: force static linking https://git.kernel.org/arm64/c/d7a49291d786
diff --git a/tools/testing/selftests/arm64/bti/Makefile b/tools/testing/selftests/arm64/bti/Makefile index 73e013c082a65..dafa1c2aa5c47 100644 --- a/tools/testing/selftests/arm64/bti/Makefile +++ b/tools/testing/selftests/arm64/bti/Makefile @@ -39,7 +39,7 @@ BTI_OBJS = \ teststubs-bti.o \ trampoline-bti.o gen/btitest: $(BTI_OBJS) - $(CC) $(CFLAGS_BTI) $(CFLAGS_COMMON) -nostdlib -o $@ $^ + $(CC) $(CFLAGS_BTI) $(CFLAGS_COMMON) -nostdlib -static -o $@ $^ NOBTI_OBJS = \ test-nobti.o \ @@ -50,7 +50,7 @@ NOBTI_OBJS = \ teststubs-nobti.o \ trampoline-nobti.o gen/nobtitest: $(NOBTI_OBJS) - $(CC) $(CFLAGS_BTI) $(CFLAGS_COMMON) -nostdlib -o $@ $^ + $(CC) $(CFLAGS_BTI) $(CFLAGS_COMMON) -nostdlib -static -o $@ $^ # Including KSFT lib.mk here will also mangle the TEST_GEN_PROGS list # to account for any OUTPUT target-dirs optionally provided by
The "bti" selftests are built with -nostdlib, which apparently automatically creates a statically linked binary, which is what we want and need for BTI (to avoid interactions with the dynamic linker). However this is not true when building a PIE binary, which some toolchains (Ubuntu) configure as the default. When compiling btitest with such a toolchain, it will create a dynamically linked binary, which will probably fail some tests, as the dynamic linker might not support BTI: =================== TAP version 13 1..18 not ok 1 nohint_func/call_using_br_x0 not ok 2 nohint_func/call_using_br_x16 not ok 3 nohint_func/call_using_blr .... =================== To make sure we create static binaries, add an explicit -static on the linker command line. This forces static linking even if the toolchain defaults to PIE builds, and fixes btitest runs on BTI enabled machines. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- tools/testing/selftests/arm64/bti/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)