[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZoppyH0wKknTwh0wTZZOctW444s5XHyEvzJr-Gag2jzARA@mail.gmail.com>
Date: Mon, 12 Feb 2024 15:05:16 -0800
From: enh <enh@...gle.com>
To: musl@...ts.openwall.com
Cc: William Roberts <bill.c.roberts@...il.com>
Subject: Re: PAC/BTI Support on aarch64
On Mon, Feb 12, 2024 at 2:46 PM Rich Felker <dalias@...c.org> wrote:
>
> 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).
depends on your toolchain version. when we added this to bionic, the
toolchain work was still happening. so you'll want to test against
whatever your oldest-supported toolchain is.
> 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.
bionic does use PAC, but i think glibc has its own "pointer mangling" thing?
> > 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?
correct.
> > 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?
well, that's the ELF note stuff i was talking about, and if you don't
have it you'll fall foul of the static linker saying "not all this
code is BTI-enabled, therefore this .so isn't", and the dynamic linker
doing nothing because the static linker effectively tells it not to.
> 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.
