[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250709184554.GQ1827@brightrain.aerifal.cx>
Date: Wed, 9 Jul 2025 14:45:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: aarch64 SME support issues
On Wed, Jul 09, 2025 at 04:26:46PM +0200, Szabolcs Nagy wrote:
> > Do you have a recommendation/preference beween masking it off or
> > dropping the __getauxval exposure for now?
> >
> > I think I'd rather mask it off, since in the (unusual but plausible)
> > case where a static-only toolchain is built, I think the libgccc
> > configure test will see the hidden __getauxval and be able to use it
> > already.
> >
> > And if we do masking, I think it makes sense to mask off all unknown
> > bits so this doesn't happen again in the future with the next new
> > thing, but I'm not sure. Does this sound reasonable? Are there any
> > cases where *hiding* a hwcap bit could result in malfunction?
>
> ok i hadnt considered the __getauxval change, i think that
> is useful to go in: it will take time to safely update libgcc
> so better to add it sooner and potentially more widely useful
> than just for SME.
>
> i think hiding a hwcap bit may lead to inconsistencies due
> to kernel behaving differently than what libc pretends,
> but i don't have a strong case, it likely can only affect
> hacky code. so likely no abi break for normal code.
Yes that's what I'd expect.
> e.g. kernel enables BTI on vdso (or static exe) and user code
> trying to indirect jump into the middle of a function after
> checking via the libc hwcap that bti is off.
>
> or creating MTE tagged objects via mprotect + instructions
> based on cpuid and then passing them to a function that is
> only MTE safe when HWCAP_MTE is set.
Note that we don't need to mask off any caps we already know the
semantics for, only SME and possibly as-yet-unassigned ones we don't
know will be safe without libc support.
> or different part of atomics code trying to detect 128bit
> lse atomics support differently (hwcap vs cpuid).
>
> note that HWCAP2 is all used up, and now the top 32 bits
> of HWCAP are getting allocated (used to be reserved when
> we thought ilp32 was a thing, now only the top 2 bits are
> kept for libc to use), musl does not have AT_HWCAP3 but
> user code may query that anyway as AT_* values are abi.
> not sure if you plan to deal with AT_HWCAP3 too.
>
> i think masking HWCAP_SME* and top bits of AT_HWCAP
> above 1<<41 should be fine for now. presumably this
> can be undone if sme support is added.
Sounds good. Should we add and mask hwcap3 too?
Rich
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.
