From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by sourceware.org (Postfix) with ESMTPS id AB9323858C2C for ; Tue, 4 Jan 2022 17:32:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AB9323858C2C Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 175296152D; Tue, 4 Jan 2022 17:32:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C74DC36AED; Tue, 4 Jan 2022 17:32:06 +0000 (UTC) Date: Tue, 4 Jan 2022 17:32:02 +0000 From: Mark Brown To: Szabolcs Nagy Cc: Catalin Marinas , Will Deacon , Jeremy Linton , "H . J . Lu" , Yu-cheng Yu , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org, Mark Rutland Subject: Re: [PATCH v7 0/4] arm64: Enable BTI for the executable as well as the interpreter Message-ID: References: <20211115152714.3205552-1-broonie@kernel.org> <20211209111048.GM3294453@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nI5cG/Ch8LIoYrmt" Content-Disposition: inline In-Reply-To: <20211209111048.GM3294453@arm.com> X-Cookie: The horror... the horror! X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 17:32:10 -0000 --nI5cG/Ch8LIoYrmt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Dec 09, 2021 at 11:10:48AM +0000, Szabolcs Nagy wrote: > The 12/08/2021 18:23, Catalin Marinas wrote: > > On Mon, Nov 15, 2021 at 03:27:10PM +0000, Mark Brown wrote: > > > memory is already mapped with PROT_EXEC. This series resolves this by > > > handling the BTI property for both the interpreter and the main > > > executable. > > Given the silence on this series over the past months, I propose we drop > > it. It's a bit unfortunate that systemd's MemoryDenyWriteExecute cannot > > work with BTI but I also think the former is a pretty blunt hardening > > mechanism (rejecting any mprotect(PROT_EXEC) regardless of the previous > > attributes). > i still think it would be better if the kernel dealt with > PROT_BTI for the exe loaded by the kernel. The above message from Catalin isn't quite the full story here - my understanding from backchannel is that there's concern from others that we might be creating future issues by enabling PROT_BTI, especially in the case where the same permissions issue prevents the dynamic linker disabling PROT_BTI. They'd therefore rather stick with the status quo and not create any new ABI. Unfortunately that's not something people have been willing to say on the list, hopefully the above captures the thinking well enough. Personally I'm a bit ambivalent on this, I do see the potential issue but I'm having trouble constructing an actual scenario and my instinct is that since we handle PROT_EXEC we should also handle PROT_BTI for consistency. --nI5cG/Ch8LIoYrmt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmHUhJIACgkQJNaLcl1U h9Bqagf/eibaFSuGH07fGReZ72Hm2cZ/rQmgFzdC3g/atP19TbZr84YcP/vQPp4L paQOqxeeRSeGvOCuo/ZCvUP/RxB7xFUNucfQW8LBalMm5oMBMNNaa4sxyYSf6K1m bYNoYazImQ5jsCsaNzMdzg7wqfJ/v0oKPLg38JEACRyE3v6yQLBx7VVb3dWPxcTS 9dauSc/sUS4oPC361aBMK7aNTWan/7n9TiUqIcb4lSJcAvThYHDUuXIMK6+LSQoA RLNIcxa5mi6q1OuMRkwxwkmVhv+tK1ERdQhdbOVeKn/FcHfc84LClIBWNt/Y7XmU 3yHKvPafAancN9yBxQLqQ9xL3LT6mw== =Gt2s -----END PGP SIGNATURE----- --nI5cG/Ch8LIoYrmt--