Re: [musl] PAC/BTI Support on aarch64

[Markus Wichmann <nullplan@gmx.net>]

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
instruction.

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; configure.sh 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
section.

> 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.

Ciao,
Markus