[PATCH v2] AArch64: Add ifunc masking tunable
Wilco Dijkstra
Wilco.Dijkstra@arm.com
Mon Jul 6 12:47:51 GMT 2026
Hi Yury,
> glibc {
> cpu {
> - name {
> + hwcaps {
> type: STRING
> }
> aarch64_bti {
> Perhaps, use another name like 'hwcapsoff' or 'hwfeatoff'?
I've used the exact same syntax and code as used for the hwcaps feature.
In general you cannot enable hardware features that you don't already have,
hence other targets do something similar. If there is ever a feature that can
be on/off, it's trivial to support.
> -tst-cpu-tunable-static-pie-TUNABLES = glibc.cpu.name=generic
> -endif
> This test is still useful and we shouldn't delete it, it should just use the
> new tunable. This test had been added to check for the failure to parse
> string tunable from a static PIE program.
OK, I'll keep it for now. But we really need a more general scheme that
disallows all absolute relocations (and it's not strictly PIE-only either, this is
an odd implementation detail of the dynamic linker - you'd expect PIC and
PIE to behave identically).
> I think this is the right approach and should simplify testing, however
> in theory it is possible that a security related ifunc choice will be
> based on the value of midr_el1, and this patch would allow to by-pass
> this. Maybe it's unlikely?
That would only be possible if you make a security feature depend on MIDR.
> + TUNABLE_GET (glibc, cpu, hwcaps, tunable_val_t *,
> + TUNABLE_CALLBACK (set_hwcaps));
> Probably a comment is needed that this tunable processing should always
> remain at the bottom of this function?
Added in v3.
Cheers,
Wilco
More information about the Libc-alpha
mailing list