Re: [Buildroot] [PATCH] Config.in: add option to ban textrels

["J. Neuschäfer via buildroot" <buildroot@buildroot.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3607 bytes --]

On Thu, May 09, 2024 at 05:40:57PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 19 Apr 2024 16:52:50 +0200
> J. Neuschäfer via buildroot <buildroot@buildroot.org> wrote:
> 
> > Ideally, this option would default to yes when a musl-based toolchain is
> > used, as musl doesn't support TEXTRELs[1] and programs with TEXTRELs
> > will crash on start-up under musl.
> > 
> > However, to avoid a large build fallout, it defaults to "no" for now.
> > After this option has been enabled in build tests for a while and some
> > of the fallout has been fixed, the default can be changed.
> > 
> > [1]: https://www.openwall.com/lists/musl/2020/09/25/4
> > 
> > Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net>
> 
> Thanks for the patch. I am not fully sure I totally grasp the issue,
> but I'm wondering if making it an option is really the right thing to
> do. If indeed TEXTRELs don't work with musl, then we should simply
> disable them.

Fair enough. My intention here was to soften the blow somewhat with
regards to how much breakage will be seen in the autobuilders, but two
points run counter to that idea:

- Any binaries built with textrels on musl would be broken anyway, and
  the current situation just hides the breakage by deferring it until
  runtime.
- I'm considering to try an allyesconfig build locally to see what breaks.
  Not sure if it's a good idea though, given the sheer number of packages :)

> 
> One thing I'm not entirely clear is that
> https://www.openwall.com/lists/musl/2020/09/25/4 states "I recently
> discovered that musl doesn't support DT/DF_TEXTREL in the main
> executable", while passing -z text will disallow TEXTREL everywhere,
> not only "main executable" but also shared libraries. Is that intended?

Hm, that's a detail that I haven't thought about.
I'm not sure if textrels in shared libraries even happen in practice.

musl's situtation is as follows, as far as I can piece it together:

- Version 0.7.12 (released in 2011) claims support for textrels in
  shared objects[1]. The code that added it (in commit v0.7.11-1-g9f17413c
  "textrel support, cheap and ugly"[2]) is still present essentially
  unchanged, but I don't understand how it works[3].
- The email from Rick Felker states it's only for legacy reasons and on
  a few architectures.
- Commit v1.1.9-20-gdc031ee0 ("add rcrt1 start file for fully static-linked PIE")[4]
  states: "all libraries being linked must be built as PIC/PIE; TEXTRELs
  are not supported at this time."

In summary, I think it's safe to forbid textrels on musl in general.


> Do you have an idea of the amount of breakage enabling -z text would
> cause? Which particular package/situation did you encounter that was
> using TEXTREL and shouldn't have in order to be compatible with musl?

I haven't investigated the total amount of breakage. The package that
prompted this change was micropython, which I recently fixed upstream[5].


Best regards,
- jn

[1]: https://git.musl-libc.org/cgit/musl/tree/WHATSNEW#n272
[2]: https://git.musl-libc.org/cgit/musl/commit/?id=9f17413c753030811761d576fdb95f200bd818d7
[3]:    for (i=0; ((size_t *)(base+dyn))[i]; i+=2)
                if (((size_t *)(base+dyn))[i]==DT_TEXTREL) {
                        mprotect(map, map_len, PROT_READ|PROT_WRITE|PROT_EXEC);
                        break;
                }
[4]: https://git.musl-libc.org/cgit/musl/commit/?id=dc031ee0b1ba11baa00cd7f0769e461a5f396c71
[5]: https://github.com/micropython/micropython/commit/7b050b366b7dacfb43779c51702a892d8f1873d0

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot