| Message ID | 20240719-ztext-v5-1-ec46696d4ed9@gmx.net |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v5] Config.in: ban textrels on musl toolchains | expand |
Hello J, On Fri, 19 Jul 2024 17:27:19 +0200 J. Neuschäfer via buildroot <buildroot@buildroot.org> wrote: > musl-libc doesn't support TEXTRELs[1] and programs with TEXTRELs will > crash on start-up under musl. > > This patch forbids the use of TEXTRELs on musl toolchains with dynamic > linking. > > To verify this patch: > > - Delete package/micropython/0001-py-nlrthumb-Make-non-Thumb2-long-jump-workaround-opt.patch > - Build micropython (before v1.23) with a musl toolchain and > BR2_SHARED_LIBS. The build should abort while linking micropython. > > [1]: https://www.openwall.com/lists/musl/2020/09/25/4 > > Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net> > --- > Changes in v5: > - Fix boolean logic (ifeq...) > - Link to v4: https://lore.kernel.org/r/20240718-ztext-v4-1-15a9744f1edb@gmx.net Applied to master, thanks. If you could monitor http://autobuild.buildroot.net/?libc=musl in the next few days to check for any issue related to this change, it would be nice. Thanks! Thomas
Hello J, On Fri, 19 Jul 2024 17:27:19 +0200 J. Neuschäfer via buildroot <buildroot@buildroot.org> wrote: > +# See also: https://www.openwall.com/lists/musl/2020/09/25/4 > +ifeq ($(BR2_TOOLCHAIN_USES_MUSL):$(BR2_STATIC_LIBS),y:) > +TARGET_LDFLAGS += -Wl,-z,text > +endif Unfortunately, this change is breaking the build of gnu-efi: http://autobuild.buildroot.net/results/e3d/e3dec7e0323a3fcb07269b3f9e73becaafeedecd/build-end.log It seems like gnu-efi uses $(TARGET_LDFLAGS) directly as arguments to the linker, not as arguments to gcc-used-as-a-linker, and the linker doesn't know about -Wl,-z,-text. So, either we to "-z text" which I believe is understood by both gcc and ld, or we somehow fix gnu-efi. Thomas
On Wed, Jul 31, 2024 at 12:03:59AM +0200, Thomas Petazzoni wrote: > Hello J, > > On Fri, 19 Jul 2024 17:27:19 +0200 > J. Neuschäfer via buildroot <buildroot@buildroot.org> wrote: > > > +# See also: https://www.openwall.com/lists/musl/2020/09/25/4 > > +ifeq ($(BR2_TOOLCHAIN_USES_MUSL):$(BR2_STATIC_LIBS),y:) > > +TARGET_LDFLAGS += -Wl,-z,text > > +endif > > Unfortunately, this change is breaking the build of gnu-efi: > > http://autobuild.buildroot.net/results/e3d/e3dec7e0323a3fcb07269b3f9e73becaafeedecd/build-end.log > > It seems like gnu-efi uses $(TARGET_LDFLAGS) directly as arguments to > the linker, not as arguments to gcc-used-as-a-linker, and the linker > doesn't know about -Wl,-z,-text. Hm, this is an interesting case, because AFAIU gnu-efi is a bare-metal library (more or less), so it won't be using the musl ld.so anyway. So it would be completely reasonable to strip out the -z text here. > So, either we to "-z text" which I believe is understood by both gcc > and ld, or we somehow fix gnu-efi. I think I prefer the first option (with an explanatory comment). I'll send a patch when I get around to it. -- jn
J., All, +Bernd and +David for x264: On 2024-07-19 17:27 +0200, J. Neuschäfer via buildroot spake thusly: > This patch forbids the use of TEXTRELs on musl toolchains with dynamic > linking. Another build failure due to this change: [...]/buildroot/output/per-package/x264/host/bin/../lib/gcc/i586-buildroot-linux-musl/12.4.0/../../../../i586-buildroot-linux-musl/bin/ld: common/x86/dct-a-8.o: warning: relocation in read-only section `.text' [...]/buildroot/output/per-package/x264/host/bin/i586-buildroot-linux-musl-gcc-ranlib libx264.a [...]/buildroot/output/per-package/x264/host/bin/../lib/gcc/i586-buildroot-linux-musl/12.4.0/../../../../i586-buildroot-linux-musl/bin/ld: read-only segment has dynamic relocations collect2: error: ld returned 1 exit status make[2]: *** [Makefile:251: libx264.so.164] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/x264-baee400fa9ced6f5481a728138fed6e867b0ff7f/.stamp_built] Error 2 make: *** [Makefile:83: _all] Error 2 There is still no failure in the autobuilders, as x264 is quite late in the alphabetical order, so it probably is just hidden by earlier failures... I have no idea what to look for to avoid those relocations in the first place, so could you have a look, please? Regards, Yann E. MORIN.
On Tue, Aug 13, 2024 at 11:09:02AM +0200, yann.morin@orange.com wrote: > J., All, > > +Bernd and +David for x264: > > On 2024-07-19 17:27 +0200, J. Neuschäfer via buildroot spake thusly: > > This patch forbids the use of TEXTRELs on musl toolchains with dynamic > > linking. > > Another build failure due to this change: > > [...]/buildroot/output/per-package/x264/host/bin/../lib/gcc/i586-buildroot-linux-musl/12.4.0/../../../../i586-buildroot-linux-musl/bin/ld: common/x86/dct-a-8.o: warning: relocation in read-only section `.text' > [...]/buildroot/output/per-package/x264/host/bin/i586-buildroot-linux-musl-gcc-ranlib libx264.a > [...]/buildroot/output/per-package/x264/host/bin/../lib/gcc/i586-buildroot-linux-musl/12.4.0/../../../../i586-buildroot-linux-musl/bin/ld: read-only segment has dynamic relocations > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:251: libx264.so.164] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/x264-baee400fa9ced6f5481a728138fed6e867b0ff7f/.stamp_built] Error 2 > make: *** [Makefile:83: _all] Error 2 > > There is still no failure in the autobuilders, as x264 is quite late > in the alphabetical order, so it probably is just hidden by earlier > failures... > > I have no idea what to look for to avoid those relocations in the first > place, so could you have a look, please? Hi Yann, sorry for the delay, I was busy with other stuff for the past weeks. I'll take a look at the libx264 textrel issue. -- jn
On Tue, Aug 13, 2024 at 11:09:02AM +0200, yann.morin@orange.com wrote: > J., All, > > +Bernd and +David for x264: > > On 2024-07-19 17:27 +0200, J. Neuschäfer via buildroot spake thusly: > > This patch forbids the use of TEXTRELs on musl toolchains with dynamic > > linking. > > Another build failure due to this change: > > [...]/buildroot/output/per-package/x264/host/bin/../lib/gcc/i586-buildroot-linux-musl/12.4.0/../../../../i586-buildroot-linux-musl/bin/ld: common/x86/dct-a-8.o: warning: relocation in read-only section `.text' > [...]/buildroot/output/per-package/x264/host/bin/i586-buildroot-linux-musl-gcc-ranlib libx264.a > [...]/buildroot/output/per-package/x264/host/bin/../lib/gcc/i586-buildroot-linux-musl/12.4.0/../../../../i586-buildroot-linux-musl/bin/ld: read-only segment has dynamic relocations > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:251: libx264.so.164] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/x264-baee400fa9ced6f5481a728138fed6e867b0ff7f/.stamp_built] Error 2 > make: *** [Makefile:83: _all] Error 2 > > There is still no failure in the autobuilders, as x264 is quite late > in the alphabetical order, so it probably is just hidden by earlier > failures... > > I have no idea what to look for to avoid those relocations in the first > place, so could you have a look, please? > > Regards, > Yann E. MORIN. I took a look, the issue is that libx264's x86 assembly is position dependent (patch coming in a separate email). For example: SECTION .text cextern pw_32 [...] INIT_MMX mmx cglobal add4x4_idct, 2,2 pxor m7, m7 .skip_prologue: movq m1, [r1+ 8] movq m3, [r1+24] movq m2, [r1+16] movq m0, [r1+ 0] IDCT4_1D w,0,1,2,3,4,5 TRANSPOSE4x4W 0,1,2,3,4 paddw m0, [pw_32] <--- here IDCT4_1D w,0,1,2,3,4,5 STORE_DIFF m0, m4, m7, [r0+0*FDEC_STRIDE] STORE_DIFF m1, m4, m7, [r0+1*FDEC_STRIDE] STORE_DIFF m2, m4, m7, [r0+2*FDEC_STRIDE] STORE_DIFF m3, m4, m7, [r0+3*FDEC_STRIDE] RET In my experience, hand-written assembly code is usually the culprit, but of course not all hand-written assembly code has these issues. -- jn
diff --git a/package/Makefile.in b/package/Makefile.in index 47a89f1ae1..1cedfefa7e 100644 --- a/package/Makefile.in +++ b/package/Makefile.in @@ -149,6 +149,15 @@ endif TARGET_LDFLAGS = $(call qstrip,$(BR2_TARGET_LDFLAGS)) +# musl's dynamic loader doesn't support DT_TEXTREL, which results in a runtime +# crash if it gets used. The "-z text" linker option issues a build-time error +# when DT_TEXREL is used, so we capture the problem earlier. +# +# See also: https://www.openwall.com/lists/musl/2020/09/25/4 +ifeq ($(BR2_TOOLCHAIN_USES_MUSL):$(BR2_STATIC_LIBS),y:) +TARGET_LDFLAGS += -Wl,-z,text +endif + # By design, _FORTIFY_SOURCE requires gcc optimization to be enabled. # Therefore, we need to pass _FORTIFY_SOURCE and the optimization level # through the same mechanism, i.e currently through CFLAGS. Passing
musl-libc doesn't support TEXTRELs[1] and programs with TEXTRELs will crash on start-up under musl. This patch forbids the use of TEXTRELs on musl toolchains with dynamic linking. To verify this patch: - Delete package/micropython/0001-py-nlrthumb-Make-non-Thumb2-long-jump-workaround-opt.patch - Build micropython (before v1.23) with a musl toolchain and BR2_SHARED_LIBS. The build should abort while linking micropython. [1]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net> --- Changes in v5: - Fix boolean logic (ifeq...) - Link to v4: https://lore.kernel.org/r/20240718-ztext-v4-1-15a9744f1edb@gmx.net Changes in v4: - Remove Config.in option, implement the whole logic in package/Makefile.in - Document how to verify - Link to v3: https://lore.kernel.org/r/20240704-ztext-v3-1-9195d06c8bd0@gmx.net Changes in v3: - drop micropython patch (already merged) - rewrite to positive logic, as suggested by Yann E. MORIN - Link to v2: https://lore.kernel.org/r/20240529-ztext-v2-0-82985032f169@gmx.net Changes in v2: - Slightly different wording - Enable the option by default on musl toolchains - Add patch to fix build of micropython Link to v1: - https://lore.kernel.org/r/20240419-ztext-v1-1-a8d5c2cfcf57@gmx.net --- --- package/Makefile.in | 9 +++++++++ 1 file changed, 9 insertions(+) --- base-commit: 89e3b2fb846506217b4767fe9165f1641a407314 change-id: 20240417-ztext-5accbab61c0a Best regards, -- J. Neuschäfer <j.neuschaefer@gmx.net>