From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3076C48BDF for ; Tue, 15 Jun 2021 15:34:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAEE96162A for ; Tue, 15 Jun 2021 15:34:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231495AbhFOPgE (ORCPT ); Tue, 15 Jun 2021 11:36:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:40492 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230076AbhFOPgE (ORCPT ); Tue, 15 Jun 2021 11:36:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5A27F61628; Tue, 15 Jun 2021 15:33:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623771239; bh=q8BZ1n+o1weaYiyieYWAIsKfcyyZyn64y14iR2bzbn8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m8fY8vjOO0Kr6eZs42TZeSsIidyQQ/MWtBuSus8HpUDznidfxpFvYW0zrrWnugIlj jVaXwWmjApZRfyat/yPjBFA0XEtiSLFBhTiRsyh4AX18gkTDkKNm+T3yQXYBFbQaD0 4FIUEzF0dFeGEqQIBWmTvvp1aIVFn66vk3MxH0VwcpeattZeGV2gX6ny8vplcNwuJK tvBeSAsYBQl2jfc4Yzjm/JfEylX/S7lh2WZzfOIhr3QJz/73n8TiWP47kihjXvps7Q gMm/6DUUGntast53CjQwRnu97GeXHWbO0/AVBkxVybpC1A3J+Yr5YPcr4T4L/QGegV b+1YtPTW2a9tA== Date: Tue, 15 Jun 2021 16:33:41 +0100 From: Mark Brown To: Dave Martin Cc: Jeremy Linton , Catalin Marinas , Will Deacon , linux-arch@vger.kernel.org, Yu-cheng Yu , libc-alpha@sourceware.org, Szabolcs Nagy , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 0/3] arm64: Enable BTI for the executable as well as the interpreter Message-ID: <20210615153341.GI5149@sirena.org.uk> References: <20210604112450.13344-1-broonie@kernel.org> <43e67d7b-aab9-db1f-f74b-a87ba7442d47@arm.com> <20210615152203.GR4187@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rCb8EA+9TsBVtA92" Content-Disposition: inline In-Reply-To: <20210615152203.GR4187@arm.com> X-Cookie: See store for details. User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org --rCb8EA+9TsBVtA92 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 15, 2021 at 04:22:06PM +0100, Dave Martin wrote: > On Thu, Jun 10, 2021 at 11:28:12AM -0500, Jeremy Linton via Libc-alpha wrote: > > Thus, I expect that with his patch applied to 5.13 the service will fail to > > start regardless of the state of MDWE, but it seems to continue starting > > when I set MDWE=yes. Same behavior with v1 FWTW. > If the failure we're trying to detect is that BTI is undesirably left > off for the main executable, surely replacing BTIs with NOPs will make > no differenece? The behaviour with PROT_BTI clear is strictly more > permissive than with PROT_BTI set, so I'm not sure we can test the > behaviour this way. > Maybe I'm missing sometihng / confused myself somewhere. The issue this patch series is intended to address is that BTI gets left off since the dynamic linker is unable to enable PROT_BTI on the main executable. We're looking to see that we end up with the stricter permissions checking of BTI, with the issue present landing pads replaced by NOPs will not fault but once the issue is addressed they should start faulting. > Looking at /proc//maps after the process starts up may be a more > reliable approach, so see what the actual prot value is on the main > executable's text pages. smaps rather than maps but yes, executable pages show up as "ex" and BTI adds a "bt" tag in VmFlags. --rCb8EA+9TsBVtA92 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDIyFQACgkQJNaLcl1U h9Ch1wf/Uux07QpS16OkwvekpnneqAZWCv9/h9QzbYGAeINqO/tnpqDOts/LmiC+ DqG/hs3yJt+XitSG9I6FNIZ0aKi0Kde0INaI0J5DJpnT80f2CMSmRKBFIFlsfObL ay9wNsVxyWnKWYHX85TLmZorbsWLk9LyD1yxgxyhtf07kvIdU+uRlIBCAHm9eEKW htVj0GSsWI1AbwQhtaxXUy3dMe7QAx8BgCGmETogsvaTca2I4duUN4e8zT6y4FN4 Y8sbxIG9vQJ0DH3nkkEMbHdVelJoa9uwQBBHXY7tbPf38N8U4MeNuY6busAYWNxp 3lgeDigJd90wHBR9IkHIAWlisTJHmw== =8dZi -----END PGP SIGNATURE----- --rCb8EA+9TsBVtA92-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D379C48BDF for ; Tue, 15 Jun 2021 19:50:46 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2BDC76128B for ; Tue, 15 Jun 2021 19:50:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BDC76128B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=buRFvukDFBGF2ujoam8zozd2OLQeAdp/yZD6zefcV5w=; b=pfNnk6rY0dEvU1D4K1BQFRm/Cl sPxep/FZOtUV+dRZV3/N4BHYo2pF47O9ozWZ/QaoA7MxxTL/KrKYeNCU1vwCbIjG13VnaJ8X2XHKy SZFmKSB1jHNYMMo3k6qpkXTX/3MKijeCWQLmWgTDIYN1xOT0I1DqVn54/6EELJ0LWb+S/ps+E4mpD h9yXU6TBV3jL1xpHfBW3ig20KEYIWuuxqyKEXapiPdI/keDzm+saZY7PzJUV+UexVIibJMkf//YvN OO7rX6dI+KEsXE0anb4s/cQjsry83e3O7QpYnLAIRkH4zgnEVx4Y65tNMxU8oU3lJ4DJ1ORCNDItv /6bTcrQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltF3C-002ZWx-CM; Tue, 15 Jun 2021 19:48:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltB4k-0010Ls-OU for linux-arm-kernel@lists.infradead.org; Tue, 15 Jun 2021 15:34:04 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5A27F61628; Tue, 15 Jun 2021 15:33:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623771239; bh=q8BZ1n+o1weaYiyieYWAIsKfcyyZyn64y14iR2bzbn8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m8fY8vjOO0Kr6eZs42TZeSsIidyQQ/MWtBuSus8HpUDznidfxpFvYW0zrrWnugIlj jVaXwWmjApZRfyat/yPjBFA0XEtiSLFBhTiRsyh4AX18gkTDkKNm+T3yQXYBFbQaD0 4FIUEzF0dFeGEqQIBWmTvvp1aIVFn66vk3MxH0VwcpeattZeGV2gX6ny8vplcNwuJK tvBeSAsYBQl2jfc4Yzjm/JfEylX/S7lh2WZzfOIhr3QJz/73n8TiWP47kihjXvps7Q gMm/6DUUGntast53CjQwRnu97GeXHWbO0/AVBkxVybpC1A3J+Yr5YPcr4T4L/QGegV b+1YtPTW2a9tA== Date: Tue, 15 Jun 2021 16:33:41 +0100 From: Mark Brown To: Dave Martin Cc: Jeremy Linton , Catalin Marinas , Will Deacon , linux-arch@vger.kernel.org, Yu-cheng Yu , libc-alpha@sourceware.org, Szabolcs Nagy , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 0/3] arm64: Enable BTI for the executable as well as the interpreter Message-ID: <20210615153341.GI5149@sirena.org.uk> References: <20210604112450.13344-1-broonie@kernel.org> <43e67d7b-aab9-db1f-f74b-a87ba7442d47@arm.com> <20210615152203.GR4187@arm.com> MIME-Version: 1.0 In-Reply-To: <20210615152203.GR4187@arm.com> X-Cookie: See store for details. User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210615_083402_870023_AFE979C0 X-CRM114-Status: GOOD ( 19.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8946526838208362867==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============8946526838208362867== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rCb8EA+9TsBVtA92" Content-Disposition: inline --rCb8EA+9TsBVtA92 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 15, 2021 at 04:22:06PM +0100, Dave Martin wrote: > On Thu, Jun 10, 2021 at 11:28:12AM -0500, Jeremy Linton via Libc-alpha wrote: > > Thus, I expect that with his patch applied to 5.13 the service will fail to > > start regardless of the state of MDWE, but it seems to continue starting > > when I set MDWE=yes. Same behavior with v1 FWTW. > If the failure we're trying to detect is that BTI is undesirably left > off for the main executable, surely replacing BTIs with NOPs will make > no differenece? The behaviour with PROT_BTI clear is strictly more > permissive than with PROT_BTI set, so I'm not sure we can test the > behaviour this way. > Maybe I'm missing sometihng / confused myself somewhere. The issue this patch series is intended to address is that BTI gets left off since the dynamic linker is unable to enable PROT_BTI on the main executable. We're looking to see that we end up with the stricter permissions checking of BTI, with the issue present landing pads replaced by NOPs will not fault but once the issue is addressed they should start faulting. > Looking at /proc//maps after the process starts up may be a more > reliable approach, so see what the actual prot value is on the main > executable's text pages. smaps rather than maps but yes, executable pages show up as "ex" and BTI adds a "bt" tag in VmFlags. --rCb8EA+9TsBVtA92 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDIyFQACgkQJNaLcl1U h9Ch1wf/Uux07QpS16OkwvekpnneqAZWCv9/h9QzbYGAeINqO/tnpqDOts/LmiC+ DqG/hs3yJt+XitSG9I6FNIZ0aKi0Kde0INaI0J5DJpnT80f2CMSmRKBFIFlsfObL ay9wNsVxyWnKWYHX85TLmZorbsWLk9LyD1yxgxyhtf07kvIdU+uRlIBCAHm9eEKW htVj0GSsWI1AbwQhtaxXUy3dMe7QAx8BgCGmETogsvaTca2I4duUN4e8zT6y4FN4 Y8sbxIG9vQJ0DH3nkkEMbHdVelJoa9uwQBBHXY7tbPf38N8U4MeNuY6busAYWNxp 3lgeDigJd90wHBR9IkHIAWlisTJHmw== =8dZi -----END PGP SIGNATURE----- --rCb8EA+9TsBVtA92-- --===============8946526838208362867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============8946526838208362867==--