[PATCH v3 2/4] aarch64: Add glibc.cpu.aarch64_bti tunable
Yury Khrustalev
yury.khrustalev@arm.com
Mon Dec 1 16:18:26 GMT 2025
On Fri, Nov 28, 2025 at 09:27:20AM -0300, Adhemerval Zanella Netto wrote:
>
> On 28/11/25 06:23, Yury Khrustalev wrote:
> > On Thu, Nov 27, 2025 at 03:51:35PM -0300, Adhemerval Zanella Netto wrote:
> >> I think this patch should be merged with the following one, since I do
> >> see much logic of adding the documentation and the tunable without the
> >> enforcement logic.
> >
> > I'm happy to do this, but here I followed the same pattern as when we
> > added GCS tunable. I also thought separate commit allows for easier code
> > review.
>
> It does, but I prefer the commits should be logical connected meaning that
> if someone trying to understand how the features was added, having the
> commit with the full functionality is easier than tracking down multiple
> commits.
OK
> >
> >> On 26/11/25 13:45, Yury Khrustalev wrote:
> >>> ---
> >>> ...
> >>>
> >>> diff --git a/manual/tunables.texi b/manual/tunables.texi
> >>>
> >>> ...
> >>>
> >>> +@deftp Tunable glibc.cpu.aarch64_bti
> >>> +This tunable controls Branch Target Identification (BTI) handling for the
> >>> +process. This handling is implemented via protecting the memory mapping
> >>> +with @code{PROT_BTI} for modules that are marked with the appropriate ELF
> >>> +property.
> >>
> >> Maybe that this is enable with the presence of GNU_PROPERTY_AARCH64_FEATURE_1_AND
> >> along with GNU_PROPERTY_AARCH64_FEATURE_1_BTI. I think it can be useful
> >> add more context on the manual.
> >
> > I wouldn't want to duplicate information explained elsewhere (and risk
> > having to maintain this place in the manual should the reference spec
> > change in the future. Also, we'd have to do it twice: for BTI and GCS
> > which doesn't seem right. I will add a link to the external document
> > though as this would indeed be helpful. Would it be OK?
>
> Do we expect the BTI flag to change? This will most likely be an ABI break.
>
> The 'appropriate ELF property' seems vague, maybe add a reference to the
> abi-aa project if the reader want additional information.
I will add a link to the appropriate spec. I think it's better not to
copy the same information in two documents.
Sent v4: https://patchwork.sourceware.org/project/glibc/list/?series=54992
Thanks,
Yury
More information about the Libc-alpha
mailing list