[Bug 297331] arm64 userland linked without Cortex-A53 erratum 843419 workaround causes intermittent SIGSEGV

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297331

            Bug ID: 297331
           Summary: arm64 userland linked without Cortex-A53 erratum
                    843419 workaround causes intermittent SIGSEGV
           Product: Base System
           Version: 15.1-RELEASE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: [email protected]
          Reporter: [email protected]

Created attachment 273524
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=273524&action=edit
lldb output

The 15.1-RELEASE arm64 userland appears to be linked without the Cortex-A53
erratum 843419 workaround (lld's --fix-cortex-a53-843419). On Cortex-A53 parts
up to r0p4 (e.g. BCM2837 / Raspberry Pi 3), this causes intermittent SIGSEGV in
unrelated userland processes. On my system the most frequent victims are tmux
and pkg(8), both dying at the same instruction in libc's vsprintf().

Environment:

FreeBSD 15.1-RELEASE-p2 releng/15.1-n283596-aadd58dddcbc GENERIC arm64
freebsd-version -kru: 15.1-RELEASE-p2 / 15.1-RELEASE-p2 / 15.1-RELEASE-p2 
hw.model: ARM Cortex-A53 r0p4 (Raspberry Pi 3, 4 CPUs, 1 GB RAM)
Userland installed via pkgbase; pkg check -s of FreeBSD-clibs and
FreeBSD-runtime passes (installed files match packages)
Toolchain per dmesg: clang/lld 19.1.7.

Symptom:

Intermittent "exited on signal 11 (core dumped)" for tmux (repeatedly) and pkg.
All tmux cores collected fault at the identical libc offset. Representative
backtrace:

thread #1, name = 'tmux', stop reason = signal SIGSEGV frame #0:
libc.so.7vsprintf [inlined] __get_locale at xlocale_private.h:0 frame #1:
libc.so.7vsprintf(str="41;1H", fmt="%d", ...) at vsprintf.c:67 frame #2:
libc.so.7sprintf at sprintf.c:55 frame #3: libtinfow.so.9tparam_internal at
lib_tparm.c:824 frame #4: libtinfow.so.9`tiparm_s(num_expected=2, tparm_type=0,
string="\033[%i%p1%d;%p2%dr") at lib_tparm.c:1279 [... tmux screen redraw path,
libevent event loop ...]
Analysis:

The faulting instruction and its context in libc.so.7 (base load address
0x83800000 in this core):

0x8393bff8 : adrp x9, 197 ; x9 = 0x83a00000 0x8393bffc : stur q0, [sp, #0x68]
0x8393c000 : cmp x10, #0x0 0x8393c004 : ldr x9, [x9, #0x220] <-- SIGSEGV here

Key observations from the core:

The ADRP sits at page offset 0xff8 (one of the last two instruction slots of a
4 KiB page), with a dependent load 3 instructions later. This is exactly the
static condition of Cortex-A53 erratum 843419 ("A load or store might access an
incorrect address"), which affects A53 revisions <= r0p4.

The load's architectural target address (x9 = 0x83a00000, offset 0x220 =>
0x83a00220) is valid: the core's mappings show [0x839f6000-0x83a01000) r--
(libc's relro segment, containing the GOT). Moreover the instruction at
vsprintf+112 successfully read the adjacent GOT slot 0x83a00218 in the same
page microseconds earlier in the same call. The trap frame registers are all
correct. A fault on a legal load with correct registers is consistent with the
erratum corrupting the address used by the load/store unit rather than the
committed register value.

Multiple cores from separate incidents fault at the identical libc offset
(verified across three tmux cores with different ASLR bases and different tparm
capability strings: cup, csr, SGR). The trigger path is any curses-style screen
update: tparam_internal() calls sprintf("%d"), whose inlined __get_locale
executes this ADRP sequence. pkg(8) cores are masked by its own SIGSEGV handler
re-raising via kill(), but pkg dies with similar intermittency.

The presence of an un-rewritten ADRP at page offset 0xff8 followed within four
instructions by a dependent load demonstrates that --fix-cortex-a53-843419 was
not applied when linking libc.so.7: the linker workaround exists precisely to
eliminate this pattern (rewriting ADRP to ADR, or routing it through a veneer).

Impact:

Any FreeBSD 15.1 arm64 system on Cortex-A53 <= r0p4 (all Raspberry Pi 3
variants and various other BCM2837/A53 SBCs) is exposed to intermittent,
hard-to-diagnose SIGSEGVs in arbitrary userland processes, with hot
printf/locale paths in libc being likely crash sites. In my case this
repeatedly killed pkg(8) mid-transaction during a pkgbase conversion, leaving
the system partially converted.

Suggested fix:

Pass --fix-cortex-a53-843419 (supported by lld) when linking the arm64 base
system libraries and binaries, as Linux distributions and the Linux kernel
build do for this erratum, or gate it appropriately for release builds
targeting platforms that include A53 <= r0p4.

-- 
You are receiving this mail because:
You are the assignee for the bug.