Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAYN94beodf3a8C9MfpM9S=FDQSgsWJ-EwXMpwoOmvbUzWbTag@mail.gmail.com>
Date: Mon, 6 Jul 2026 18:54:41 +0400
From: Andrey Smirnov <smirnov.andrey@...il.com>
To: musl@...ts.openwall.com
Subject: Re: aarch64: TLSDESC to a NEEDED shared library resolves via
 __tlsdesc_static to an offset outside the main thread's static TLS block
 (SIGSEGV at startup)

Please disregard this message, it looks to be cross-compilation issue
with rust on arm64, not musl issue.

Sorry.

On Mon, Jul 6, 2026 at 6:25 PM Andrey Smirnov <smirnov.andrey@...il.com> wrote:
>
> We hit a rustc crash (1.96.1) compiled with muscl on aarch64 (it works
> just fine on x86_64).
>
> This is a report of our findings so far, but we might be missing something.
>
> Summary: a thread-local in a NEEDED (startup) shared lib is accessed
> via TLSDESC; musl wires the descriptor to __tlsdesc_static with tpoff
> 0x5f88, but that offset is past the main thread's allocated static TLS
> block, so the access faults. Same program on x86_64/musl works because
> it uses traditional GD (__tls_get_addr, dynamic TLS) rather than
> TLSDESC.
>
> Environment: musl 1.2.6, aarch64 (TLS variant I), dynamically linked;
> crashing binary is rustc, thread-local in NEEDED librustc_driver-*.so
> (PT_TLS memsz 0x5f90 ≈ 24 KiB); LLVM 22 (aarch64 defaults to TLSDESC).
>
> Symptom + ptrace evidence: the faulting instruction is the standard
> aarch64 TLSDESC sequence; at the fault: x0(tpoff)=0x5f88, x27(TP)=…,
> si_addr = TP+0x5f88 (unmapped). Descriptor slot0 = &__tlsdesc_static,
> slot1 = 0x5f88. /proc/self/maps shows only ~12 KiB mapped around TP,
> so TP+0x5f88 (~24 KiB) is out of bounds.
>
> x86_64 comparison — same symbol uses R_X86_64_DTPMOD64/DTPOFF64
> (__tls_get_addr), never touches the static block → works.
>
> There is no minimal C reproducer: a 32 KiB __thread in a NEEDED lib,
> constructor access, dlopen, and initial-exec TLS each work in
> isolation on this musl; only the real large librustc_driver triggers
> it.
>
> Question: is musl expected to place a large NEEDED lib's TLS in the
> main-thread static block and resolve TLSDESC via __tlsdesc_static,
> sized to cover it? Or must toolchains avoid
> TLSDESC-to-large-NEEDED-lib on aarch64 (emit traditional GD like
> x86_64)?



-- 
Andrey Smirnov / ანდრეი სმირნოვ

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.