[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