Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Feb 2024 18:51:47 +0100
From: Markus Wichmann <>
Cc: Rich Felker <>, enh <>
Subject: Re: PAC/BTI Support on aarch64

Am Tue, Feb 13, 2024 at 08:47:42AM -0600 schrieb William Roberts:
> It should. Is there a known minimal tool chain requirement and I can test?

Typically the first C99 compiler or the first aarch64 compiler,
whichever is younger.

> No, anywhere branches are allowed, a BTI instruction must be the first
> instruction. BTI is just a way for software to say, hey this is a
> valid jump/branch
> target, allow it. This reduces the amount of gadgets available to an
> attacker, which
> is why libc is such a juicy target, as it's in everything. A lot of
> things static link it,
> which effectively turns it off for the whole process.

So this means there must be a BTI instruction following every single BL

But in the end this isn't that much different from endbr64 on the PC.
Whatever happened to those patches, BTW?

> Yes, so the kernel will manage the EL1 register flag for this, and then
> mprotect sets the PROT_BTI flag during dlopen().

Well, this is a novelty. This is the first time there will be an
arch-specific flag in mmap()/mprotect() for the musl dynlinker. So far
that code has been entirely portable.

> It's important to note, that even when enabling the assembly code files, if the
> C level source is not built with -mbranch-protection=standard, the feature will
> remain off for the library.

Arch-specific compiler flags are not a problem; can add
those as needed.

> I can't think of anything like this offhand, but aarches may want to add prot
> flags to mprotect calls.

That hasn't happened yet. Of course, this may be as simple as adding a
static inline function. The fact that the important information is in a
note section is yet another novelty, of course. So far, the important
information (even arch-specific) has been contained in the dynamic

> it usually
> #ifdef aarch64
> if (gnu_notes_bti_set && (prot & PROT_EXEC)) {
>     prot |= PROT_BTI;
> else {
>     prot &= ~PROT_BTI;
> }
> #endif
> mprotect(..., prot);

So far we have managed to steer clear of conditional inclusion, and I
think we should try to keep it that way.


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.