From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 94B852494E for ; Mon, 12 Feb 2024 23:46:56 +0100 (CET) Received: (qmail 26288 invoked by uid 550); 12 Feb 2024 22:43:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26253 invoked from network); 12 Feb 2024 22:43:55 -0000 Date: Mon, 12 Feb 2024 17:46:58 -0500 From: Rich Felker To: William Roberts Cc: musl@lists.openwall.com Message-ID: <20240212224657.GA4163@brightrain.aerifal.cx> References: <20240212184236.GZ4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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