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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 95CA123FC4 for ; Tue, 13 Feb 2024 00:18:47 +0100 (CET) Received: (qmail 31864 invoked by uid 550); 12 Feb 2024 23:15:47 -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 31826 invoked from network); 12 Feb 2024 23:15:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707779914; x=1708384714; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0beOtu1GyK2OR/tln/8KOeWTXEf3OvHq/YLS84+O6p4=; b=MC8XSnNjXthTiK1dCJB4CIm1jY7WoUrXpU3c2GSZDjVQeCX7ImVjPd1qPcqiFwxY0y E8yQmOotyVgYerRXsCIkEaCUtJT05wDoz2qFC6Gl3jHUTwg+uLqXJR+ipvWe5HQxlrdp h2jLCCtybjVp30Jgow8F7dOZ/jrw2iu+OgGJNlFhv3eHQoIEVIzszn2J6UOd7y8Svaht +kNpgvwwxjE2YCOi+6v3PIjF3FFk+mfIiYAbRQecYEGy7lNsStFn2gmoRNWs16JqjH2x pF5S/5ZaFK/OB1VMXQ55XAxRACMXsMA/OJaVbV52A20LqBmmY/intol81QWYuJffG/6t xi4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707779914; x=1708384714; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0beOtu1GyK2OR/tln/8KOeWTXEf3OvHq/YLS84+O6p4=; b=sflp6T7uBxFgyZWcAKj+qpXah7ZwLKmku9EgPslBcSgaAczkLc+fsT58BxXrnfoKlj h2rNpw0j2cSszAlBqEahDYtEtYP72FFb2NJ2SDfjAEhNs/mxE1lDYdEqGdbcy4GoPgTb 8KHOirIEefNEoyIptIx41L9pFZg/3cl0iH5fxGibeCGEMv37aT5yHH4Y06f6AdMH8zS1 sckqQymZY1Q/NI1oGRVrw0pm/9U6dn34rhpnK/JzI//nzuQYQtcL1byFNurkUwSiZco1 r6g1GoZ5/6ziIlqn+rV3giErtZH8PABaGebVqThEeazTwAD5L0U3/+X8t8gSCDhtzjtA rwfw== X-Gm-Message-State: AOJu0Yzd0hxIuj/A1WODg4nGuQtQR2cREoIGpApFwx8GhrHysqrQRu++ VPcj0jupulNY0n/XJ8r4lwgsOv9TwQX9adp6UKdlE/n1L0UBc2KZpJ+xfPM1ECDyZBWaZCahcdp rDIGodLsxezpUq1GQwarRHyMcanA= X-Google-Smtp-Source: AGHT+IHLhkFbTBCjEYleTGP63BRANTgg/xibSTFqjGD3Q+HEm1/EFYmf3uWHzI94sRJs6ze4igOmH3234xKQFMt+pLk= X-Received: by 2002:ac2:4909:0:b0:511:8e03:c91e with SMTP id n9-20020ac24909000000b005118e03c91emr2720661lfi.7.1707779913708; Mon, 12 Feb 2024 15:18:33 -0800 (PST) MIME-Version: 1.0 References: <20240212184236.GZ4163@brightrain.aerifal.cx> <20240212224657.GA4163@brightrain.aerifal.cx> In-Reply-To: From: William Roberts Date: Mon, 12 Feb 2024 17:18:22 -0600 Message-ID: To: enh Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] PAC/BTI Support on aarch64 On Mon, Feb 12, 2024 at 5:05=E2=80=AFPM enh wrote: > > On Mon, Feb 12, 2024 at 2:46=E2=80=AFPM Rich Felker wro= te: > > > > On Mon, Feb 12, 2024 at 03:25:48PM -0600, William Roberts wrote: > > > On Mon, Feb 12, 2024 at 12:42=E2=80=AFPM 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 duplic= ate > > > > > 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=3Dstandard > > > > > > Just the ASM labels need the first instruction to be a BTI. They're i= n > > > 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. > You just use the hint instructions, they are understood by old toolchains. But you can only support a subset of the BTI/PAC instructions but it's been enough for most projects that follow the normal ABI conventio= ns like OpenSSL/BoringSSL,etc, but not enough for libffi for example. > > 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 as in inline asm? Unless it's a branch target, no need. > > quite as trivial as adding something to CFLAGS. That's not really what I said... > > > > 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" thi= ng? You need it, as the first instruction from a branch (where longjmp returns = to) needs to be a BTI instruction. > > > > 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=3D-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. Yep, well said ENH. It's been since Android since we crossed paths :-). It's not that hard to annotate an asm file :-p I forget what project (I think it was gnutls, but they just use openssl's code for the asm) but I just put it in a header file and by virtue of #include'ing it you get= the notes added. > > > Rich