mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: William Roberts <bill.c.roberts@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] PAC/BTI Support on aarch64
Date: Mon, 12 Feb 2024 17:46:58 -0500	[thread overview]
Message-ID: <20240212224657.GA4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAFftDdpoPk_=OQAZeohTWL4j6NcNte_eOG=euEq2u+WQYDSY2w@mail.gmail.com>

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

  parent reply	other threads:[~2024-02-12 22:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 16:38 William Roberts
2024-02-12 18:42 ` Rich Felker
2024-02-12 21:25   ` William Roberts
2024-02-12 21:34     ` enh
2024-02-12 22:46     ` Rich Felker [this message]
2024-02-12 23:05       ` enh
2024-02-12 23:18         ` William Roberts
2024-02-13  2:08           ` Rich Felker
2024-02-13 14:47             ` William Roberts
2024-02-13 17:51               ` Markus Wichmann
2024-02-14  2:19                 ` Rich Felker
2024-02-14  3:19                   ` William Roberts
2024-02-14  4:44                   ` Markus Wichmann
2024-02-14 13:32                     ` Thorsten Glaser
2024-02-14 14:03                       ` Rich Felker
2024-02-14 14:12                         ` Thorsten Glaser
2024-02-15 13:29                   ` Stefan O'Rear
2024-02-15 14:06                     ` Rich Felker
2024-03-02 14:33                       ` Szabolcs Nagy
2024-03-02 14:45                         ` Rich Felker
2024-02-15  0:03             ` Szabolcs Nagy
2024-02-15  0:22               ` enh
2024-02-15  9:18                 ` Szabolcs Nagy
2024-02-19 23:54   ` Fangrui Song
     [not found]   ` <DS7PR12MB57659BC5D5536574D1B91D26CB502@DS7PR12MB5765.namprd12.prod.outlook.com>
2024-02-20  6:21     ` Anton Korobeynikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240212224657.GA4163@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=bill.c.roberts@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).