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_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 852262537A for ; Tue, 20 Feb 2024 13:20:05 +0100 (CET) Received: (qmail 16279 invoked by uid 550); 20 Feb 2024 12:09:21 -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 11626 invoked from network); 20 Feb 2024 06:19:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=korobeynikov.info; s=google; t=1708410145; x=1709014945; 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=2wECVvoN5XwWZW+Bv0hJ9St/CYF9c6cfQV7UG0TzySo=; b=dE5Z2z0vJ/r8Q5/b8oN+DmkKvqTbCcS0f3u9gkGflnHHx8k9HqAKkbyxmfDzymdh1a TDdda7Ec8eYPWelDdXMtOleDjGTJ7GcWTC9Rmfl9UPyWHpaT7LoojIyXwEtU0KgSvDGV b2NSsHflobIYRddY7ViFG5jBECIIRefCXA3pw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708410145; x=1709014945; 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=2wECVvoN5XwWZW+Bv0hJ9St/CYF9c6cfQV7UG0TzySo=; b=dgwCbasnD4wlWKJPVg1lCWhFY+DXsNdZq+jIYj6vj1t8BPxILPeyYQU0V2jpex5IB4 dmdsg4hRYZi4zDNYndlWT3Bn6DaCPVzCdYkOvwCTgoV9HYUZrpwgfjm/Mjf6xBHuUtrh RUTlrfOYbar3AF1rb2htsoZezJruXy3+Z6p/uOiMq3nip33yS0LY6xZsLt2wMaxX6J7M cqdQzLOQYKj/IbaIAlz4DLhlexrPy+I9jwmhVdo4txls2DE73XTtc9tuw/uCRFdnMDZH gazeRbeJ+SW3mZ+zopzsPrJfaynMR8Z6s9kxf+XVOIUkbS6YBreY0M/9p8J/vB54ltHW 6ULQ== X-Gm-Message-State: AOJu0YxVtmG3w5MbsfKMc2EoJqJS5kW36PnisAVyoRysg/5ac0TO7FfA BQYb44hNZchqOb6XnqBXugVPKU5XoN6VHS9O+nwZbgT8HdcnnMtGlmz+p0JlfeOyOgrTQLx4wd3 D3B4Gu+g4sdElwWBrW/p5N6wxvJNxmhYCKHSD X-Google-Smtp-Source: AGHT+IEwZbSMqZlc6Ffz6iLE3qqM4oi4faVJMyADonA5XEDwc7x07J8ON3ncXieBmxLj4Rh4qLhMlpgO+EszwaGJMQw= X-Received: by 2002:a2e:300d:0:b0:2d2:39fa:822c with SMTP id w13-20020a2e300d000000b002d239fa822cmr2645735ljw.35.1708410145204; Mon, 19 Feb 2024 22:22:25 -0800 (PST) MIME-Version: 1.0 References: <20240212184236.GZ4163@brightrain.aerifal.cx> In-Reply-To: From: Anton Korobeynikov Date: Mon, 19 Feb 2024 22:21:58 -0800 Message-ID: To: Fangrui Song Cc: musl@lists.openwall.com, William Roberts Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] PAC/BTI Support on aarch64 Thanks Fangrui! For PAC / BTI no support from the C standard library is required. All changes are ordinary source code changes and only assembler sources should contain proper annotations / notes / BTI checks. The links above are about pointer authentication ABI (aka "arm64e"). PAC / BTI could be considered as part of it, but only a small one. Over the last few months we have been working on bringing pauth to ELF-based platforms. Our aim is to have pauth ABI support to be released as a part of LLVM 19. That github Access Softek repo is a downstream fork that contains rebased Apple changes to frontend, intrinsics, etc. and ELF codegen bits. We are working on upstreaming code from it to LLVM mainline. For pauth more deep interaction with standard library is required, as dynamic loader should process pauth relocations, and sign pointers as needed. Plus, some additional handling of the gnu.note segment would be necessary as one would need to e.g. prohibit loading of DSOs with incompatible ABI. We are having a proof-of-concept patch for MUSL to process pauth relocations (https://github.com/access-softek/musl/pull/1). We have not submitted it to MUSL upstream as there are lots of moving pieces and we do not want to submit something that could be changed (e.g. reloc numbers already changed once). Certainly, for pauth support additional code changes to assembler sources would be required. As well as ABI marking. PS: Please CC me on responses as I am not subscribed. On Mon, Feb 19, 2024 at 4:01=E2=80=AFPM Fangrui Song wrote: > > On Mon, Feb 12, 2024 at 10:42=E2=80=AFAM Rich Felker wr= ote: > > > > 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 managable and acceptable cost. > > > > Rich > > Cc +Anton (other messages of this thread can be found at > https://www.openwall.com/lists/musl/2024/02/12/ ). > > Per https://discourse.llvm.org/t/llvm-pointer-authentication-sync-ups/626= 61/23 > and an lld/ELF patch > > * https://github.com/access-softek/llvm-project/commits/elf-pauth > * https://github.com/access-softek/musl/tree/dkovalev/pauth-code-drop > > contains a prototype. > > > We verified that LLVM testsuite compiled with pauth successfully passes= on pauth-enabled AArch64 board. > > https://www.openwall.com/lists/musl/2024/02/12/ > > It looks like there will be an LLVM Pointer Authentication discussion > in a few hours: > https://calendar.google.com/calendar/u/0/embed?src=3Dcalendar@llvm.org --=20 With best regards, Anton Korobeynikov