[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240212224657.GA4163@brightrain.aerifal.cx>
Date: Mon, 12 Feb 2024 17:46:58 -0500
From: Rich Felker <dalias@...c.org>
To: William Roberts <bill.c.roberts@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: PAC/BTI Support on aarch64
On Mon, Feb 12, 2024 at 03:25:48PM -0600, William Roberts wrote:
> On Mon, Feb 12, 2024 at 12:42 PM Rich Felker <dalias@...c.org> wrote:
> >
> > On Mon, Feb 12, 2024 at 10:38:50AM -0600, William Roberts wrote:
> > > Hello,
> > >
> > > I was just wondering if there was any work being done to support PAC
> > > and BTI in aarch64? I could add support but didn't want to duplicate
> > > the work.
> >
> > I'm not aware of any active work on this, but before writing a full
> > implementation, it would be really helpful to start with a basic
> > proposal for the scope of changes needed to make it work to assess
> > whether these are manageable and acceptable cost.
>
> It's a matter of building with -mbranch-protection=standard
>
> Just the ASM labels need the first instruction to be a BTI. They're in
> the NOP space
> so they are backwards compatible, older hardware will just NOP it.
I think it's a little more elaborate than that. Those asm instructions
need to be added (probably as .instr or .word or something, unless
there's a way to spell this particular nop that existing tooling will
understand). Or it could be made conditional, but that would require
converting any asm that's not already .S files to .S. Not bad, but not
quite as trivial as adding something to CFLAGS.
I also wondered if [sig]setjmp/longjmp would be affected, but probably
not.
> It's been done for many projects, glibc and bionic have it. The
> problem with BTI is that when one item in the link
> list doesn't support BTI the loader/linker turns it off. So when it's
> something like a libc that is fundamental in the link chain,
> it turns it off for everything.
This presumably requires some kind of machinery for how dynamic
linking will work, and possibly turning it off if a library without it
is dlopened?
My understanding doing some brief searches though was that you can
individually mprotect it off in certain regions. So maybe it's
possible to just enable only for DSOs that support it?
> The initial scope of code changes would be what's reported when
> LDFLAGS=-Wl,-zforce-bti,--fatal-warnings
Is there a way to disable these warnings so that every asm file does
not need to be cluttered with annotations?
Rich
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.
