[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Feb 2024 18:51:47 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, enh <enh@...gle.com>
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
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
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.
