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,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 9E510251C0 for ; Tue, 13 Feb 2024 00:05:45 +0100 (CET) Received: (qmail 1974 invoked by uid 550); 12 Feb 2024 23:02:45 -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 1939 invoked from network); 12 Feb 2024 23:02:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707779132; x=1708383932; 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=hFUrvz/C0NAhKkbDujV1DHU99YHr4p1NMWAp9uVUQPc=; b=v9YRv6Z6h6I8ile/m4/nV/DXq1YrAHqXcVaFARKe3V/tz7N8S+5VfO3oFM6VIdG4+Y 4OcA5kHGymOndWiIR+ZnyDMVvHkSbnQOh5X4Nw5qonovrd2Aow1UuBWehw4SR7iStTZp 2ZEdSF0+cv5gZDADxfOtUGYugHzGTlFVtX1GpxyUQAzzrzZulM5olM/6XF9JLJ82rKsd 98/a8pJ2B5dCihpJFAbRoNCRJuR5jvOj2I+m/7oGyBhRLlSJuiUOwC+O3tE2xAXyYmvQ iCcNA9YAX84wH+QRiDpiP5gPgswYEdCYk2RqpCQqViyP3rhPqKMu3IVtFPom+ANbIFvh FNYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707779132; x=1708383932; 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=hFUrvz/C0NAhKkbDujV1DHU99YHr4p1NMWAp9uVUQPc=; b=TNYimNUR/JG6Qwqt6Qo01a3u0THOjnq4fVsZ+/iqmqWuf8Osar165Tqlz61kXjztjJ Ie6+2d/UtlSgVqproCc31fG9z5ODCIfoVl0lPBjIS4jfbsTNmLKIUoD/D88sxobcI9Vt HpS8S9krS3PKUV1BycFm+gzpko3kOlWbh2JocMvBsCtvkPJE/VEO1NakGZgMGkna5jaD 2hXJJol/fC7z4geBPskt2Re/g4dwf1L1+lNZy7MP0ib6s/kNsvEn5fsYZS5wnHNWbUfo E1YYJWIExW5eozNCogce8ty/ERMbi3lSsMjVE+88YHAQmrurQZThXhmMhH7Coyi9dcCT x0PQ== X-Gm-Message-State: AOJu0YzFvtgMn++jVXJJIL8oe0YgZCzj4lc8sOPQaRLbQ3IgjnhoPeu2 Vaq/t7OZd3JzBf9uyB383U04YuGorXuzbnrT4W5DNY05NKyI+Qz2I0fYpxs/SI2xHHM+x26GnAM CLf+i6oCHaUKMsJQXhnwAvjzZV0vWsoKHSl73UbuuCPIZOWf4RvtT X-Google-Smtp-Source: AGHT+IFLmSdsW4Ou+JLk6wYWXX6yDVobzaCwXPamIc6tVlehwaSnzH/zd1ntzAWmZg4qv6Q/OszCka4jXXemYnJEiOA= X-Received: by 2002:a05:6214:5787:b0:68c:cc45:7981 with SMTP id lv7-20020a056214578700b0068ccc457981mr9634609qvb.16.1707779131545; Mon, 12 Feb 2024 15:05:31 -0800 (PST) MIME-Version: 1.0 References: <20240212184236.GZ4163@brightrain.aerifal.cx> <20240212224657.GA4163@brightrain.aerifal.cx> In-Reply-To: <20240212224657.GA4163@brightrain.aerifal.cx> From: enh Date: Mon, 12 Feb 2024 15:05:16 -0800 Message-ID: To: musl@lists.openwall.com Cc: William Roberts 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 2:46=E2=80=AFPM Rich Felker wrote= : > > 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 PA= C > > > > and BTI in aarch64? I could add support but didn't want to duplicat= e > > > > 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 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=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. > Rich