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=-1.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE,URIBL_BLACK 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 61037221E5 for ; Tue, 13 Feb 2024 18:52:07 +0100 (CET) Received: (qmail 3731 invoked by uid 550); 13 Feb 2024 17:49:05 -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 3693 invoked from network); 13 Feb 2024 17:49:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1707846710; x=1708451510; i=nullplan@gmx.net; bh=S0llwp/sb7lrWIe87AfkbpR/3M2UrbRtESxORXoXdIg=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=TVxcqVs+vwD4aE2Cojcns0GaNes5nNes5N78RaeXJ7Djfyse6AsDgB7gmW64KHeo u28zL86wsYZQLoI+XgExdz4ZuTcx51keZpDr0BmFvgJHuHMZcFpzUHrW0WBIrJNXn FxCgoyIo5IdbhMKTVuoc6IBPh1w6mOpyFQxtr7rhgV1LVMWZIwyfAMnOh1N4SFL8S 91t2z66nk00YV0h54LDSRcy2TlLBglewKUMoIp5ISXzFbeSA1n6otCZ/X22me3+VK 997swl67I6VkzW4Ts/OpyfjuZgu2zK5I35X4YQM8Us84HSNMXDJtgifrX8Vn9JONJ lt0LVDPQqgqy77R7oQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Tue, 13 Feb 2024 18:51:47 +0100 From: Markus Wichmann To: musl@lists.openwall.com Cc: Rich Felker , enh Message-ID: References: <20240212184236.GZ4163@brightrain.aerifal.cx> <20240212224657.GA4163@brightrain.aerifal.cx> <20240213020834.GB4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:v5ZU8/ODDXpybSq05KHsw8yKVsPbU4zsEc7gQmC7j+n9YztJFfe zeegG0IuMVueW7BUxnh9YtcZveZ7mYHY13cawvubH7AwnV/ABztzYnc4YtBS2IwpC4jBDr9 mi7Yw9Pq91OWEj63vRHL9a2ARQZXEjhKH45UGrJgIPZtgZecMVdQEddU078ZYFUkmnCvhLG ogOF1H04e8jVXIdQgK/Qw== UI-OutboundReport: notjunk:1;M01:P0:aR7rRV/EjnM=;NXPfWJjZUQQQ9ssbZLsIzb9g8XH ufZm1CAK4zlpMQqyDrrFw9dtKPmDaeQYwv1hD3OTWc3epmEmHrEM2S9qNzuaOHQ/WVVru8kXg YGfW/E8FUIWPoK8734zU50bwAZvfm2ukBx130hyOa7k7Mk3SlHgAGm7BLaVusCyb1f7e0X066 kkvNUGKL0o72NDJBM9C3cPJbW/7QjBAmbpNYJiEsip9vxas4h3NrHf6rGtj1OBKTTjBOXZyWd 2AxCA3F43mh5ltr03GQWDB0O2Awts3ZfIF8YFy10CHIa8od8VK4XstoFxvxjPeNf/xgp0sdGH c/9HO+wDuaYTKvjQK71jtjLL/Jcr69lXVmGEWxNkODGvvyK1x7Lv4JERTrDPVTGKbbskt5vDh K2RfrvV4nkym0TC6XHeMwN9hTzyNIxLvPgpd0kAbwpKlZcLyB86oLhU2rUzijCs0lRwdMB+2+ 0H0Ap3rDYGwTCaBMipRwgs/PsxRYf09vAf3zEtw6AbaOQ4+uAvi4LseHLKQqcLtDX8BNxmaE+ ORMq5A0NsEQlTEpK+8T+SWnPJyNrxVXBWy1WmqoTKcxgJRX5EwIHE1UV7jKq+6CkFWqW29bum 7eGGXYrvSUFooFXZQzeCRqDAsfbWeJ4W+i9DXMCK3cur0n6QvnfG1sXXsS0Geycqct1WhV4Wg LUIKGJi8pOyz5iTNsPRwW0EXVbkGHxO1JOqC/rb3VbcOsg4F/eBVvSgvH4xDcV3fteyiJbpma eyRfRA1eZXqV9dBpZOBy+cvq0LGYczqROSuVgIn+G2icRrrjdaUS1qX5agPegyVnkQTlWirkM 8rXuSQV4Nd7N5F4fLSYRwkQ1llmG3sLgMRG1XVf7Xg7+4= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] PAC/BTI Support on aarch64 Am Tue, Feb 13, 2024 at 08:47:42AM -0600 schrieb William Roberts: > It should. Is there a known minimal tool chain requirement and I can tes= t? > Typically the first C99 compiler or the first aarch64 compiler, whichever is younger. > > No, anywhere branches are allowed, a BTI instruction must be the first > instruction. BTI is just a way for software to say, hey this is a > valid jump/branch > target, allow it. This reduces the amount of gadgets available to an > attacker, which > is why libc is such a juicy target, as it's in everything. A lot of > things static link it, > which effectively turns it off for the whole process. > So this means there must be a BTI instruction following every single BL instruction. But in the end this isn't that much different from endbr64 on the PC. Whatever happened to those patches, BTW? > Yes, so the kernel will manage the EL1 register flag for this, and then > mprotect sets the PROT_BTI flag during dlopen(). > Well, this is a novelty. This is the first time there will be an arch-specific flag in mmap()/mprotect() for the musl dynlinker. So far that code has been entirely portable. > It's important to note, that even when enabling the assembly code files,= if the > C level source is not built with -mbranch-protection=3Dstandard, the fea= ture will > remain off for the library. > Arch-specific compiler flags are not a problem; configure.sh can add those as needed. > I can't think of anything like this offhand, but aarches may want to add= prot > flags to mprotect calls. > That hasn't happened yet. Of course, this may be as simple as adding a static inline function. The fact that the important information is in a note section is yet another novelty, of course. So far, the important information (even arch-specific) has been contained in the dynamic section. > it usually > #ifdef aarch64 > if (gnu_notes_bti_set && (prot & PROT_EXEC)) { > prot |=3D PROT_BTI; > else { > prot &=3D ~PROT_BTI; > } > #endif > > mprotect(..., prot); > So far we have managed to steer clear of conditional inclusion, and I think we should try to keep it that way. Ciao, Markus