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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FBC2C433EF for ; Wed, 16 Feb 2022 13:34:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232449AbiBPNeo (ORCPT ); Wed, 16 Feb 2022 08:34:44 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:55056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230237AbiBPNen (ORCPT ); Wed, 16 Feb 2022 08:34:43 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6633F2AB512 for ; Wed, 16 Feb 2022 05:34:31 -0800 (PST) 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 07DC961731 for ; Wed, 16 Feb 2022 13:34:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7D8FC340EC; Wed, 16 Feb 2022 13:34:28 +0000 (UTC) Date: Wed, 16 Feb 2022 13:34:25 +0000 From: Catalin Marinas To: Will Deacon Cc: Mark Brown , Szabolcs Nagy , Jeremy Linton , "H . J . Lu" , Yu-cheng Yu , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org Subject: Re: [PATCH v8 0/4] arm64: Enable BTI for the executable as well as the interpreter Message-ID: References: <20220124150704.2559523-1-broonie@kernel.org> <20220215183456.GB9026@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220215183456.GB9026@willie-the-truck> Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Tue, Feb 15, 2022 at 06:34:56PM +0000, Will Deacon wrote: > On Mon, Jan 24, 2022 at 03:07:00PM +0000, Mark Brown wrote: > > Deployments of BTI on arm64 have run into issues interacting with > > systemd's MemoryDenyWriteExecute feature. Currently for dynamically > > linked executables the kernel will only handle architecture specific > > properties like BTI for the interpreter, the expectation is that the > > interpreter will then handle any properties on the main executable. > > For BTI this means remapping the executable segments PROT_EXEC | > > PROT_BTI. > > > > This interacts poorly with MemoryDenyWriteExecute since that is > > implemented using a seccomp filter which prevents setting PROT_EXEC on > > already mapped memory and lacks the context to be able to detect that > > memory is already mapped with PROT_EXEC. This series resolves this by > > handling the BTI property for both the interpreter and the main > > executable. > > This appears to be a user-visible change which cannot be detected or > disabled from userspace. If there is code out there which does not work > when BTI is enabled, won't that now explode when the kernel enables it? > How are we supposed to handle such a regression? If this ever happens, the only workaround is to disable BTI on the kernel command line. If we need a knob closer to user, we could add a sysctl option (as we did for the tagged address ABI, though I doubt people are even aware that exists). The dynamic loader doesn't do anything smart when deciding to map objects with PROT_BTI (like env variables), it simply relies on the ELF information. I think that's very unlikely and feedback from Szabolcs in the past and additional testing by Mark and Jeremy was that it should be fine. The architecture allows interworking between BTI and non-BTI objects and on distros with both BTI and MDWE enabled, this is already the case: the main executable is mapped without PROT_BTI while the libraries will be mapped with PROT_BTI. The new behaviour allows both to be mapped with PROT_BTI, just as if MDWE was disabled. I think the only difference would be with a BTI-unware dynamic loader (e.g. older distro). Here the main executable, if compiled with BTI, would be mapped as executable while the rest of the libraries are non-BTI. The interworking should be fine but we can't test everything since such BTI binaries would not normally be part of the distro. If there are dodgy libraries out there that do tricks and branch into the middle of a function in the main executable, they will fail with this series but also fail if MDWE is disabled and the dynamic linker is BTI-aware. So this hardly counts as a use-case. For consistency, I think whoever does the initial mapping should also set the correct attributes as we do for static binaries. If you think another knob is needed other than the cmdline, I'm fine with it. -- Catalin 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8FD19C433F5 for ; Wed, 16 Feb 2022 13:35:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding: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-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VGHFr0XbMTcsQsvZayV99z1srAAdgptfDKl0c9kcbpI=; b=HltYDC2fcfniT4 IFt3tFQVrecyIv3P/+BxvAMYGQsrepiBOKwhUAh6DgQVCmoK0jfBSFH9AD43/MbJtmu3xouM2LodF kdmyowxgOseUxSwCoF49O1PgcYijwMu9ZSK3ZXzP9WxNXljnGRfDenR7wzDTdRTN/8VxAxmE3+htf sckVUzmonhuYldkbyLFgqn0Dt1n68Qoy7W1RRs4pDpNZMGIPP7jKckWc8zVyjJaqkfatwE6OyNnkj vIjgFs8MjHyxHNjGbH0t28fIV8FZMWeS/8x1WggqI/z++Tr/fu+SMI6LlhR3ZK5S/yz5Sl48SFY2K g0Ykf6hcGJk0sf3SOXEQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKKS6-007DHk-V2; Wed, 16 Feb 2022 13:34:39 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKKS1-007DF7-To for linux-arm-kernel@lists.infradead.org; Wed, 16 Feb 2022 13:34:36 +0000 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 ams.source.kernel.org (Postfix) with ESMTPS id A6DF5B819E8; Wed, 16 Feb 2022 13:34:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7D8FC340EC; Wed, 16 Feb 2022 13:34:28 +0000 (UTC) Date: Wed, 16 Feb 2022 13:34:25 +0000 From: Catalin Marinas To: Will Deacon Cc: Mark Brown , Szabolcs Nagy , Jeremy Linton , "H . J . Lu" , Yu-cheng Yu , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org Subject: Re: [PATCH v8 0/4] arm64: Enable BTI for the executable as well as the interpreter Message-ID: References: <20220124150704.2559523-1-broonie@kernel.org> <20220215183456.GB9026@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220215183456.GB9026@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220216_053434_295731_4B79E665 X-CRM114-Status: GOOD ( 29.66 ) 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 15, 2022 at 06:34:56PM +0000, Will Deacon wrote: > On Mon, Jan 24, 2022 at 03:07:00PM +0000, Mark Brown wrote: > > Deployments of BTI on arm64 have run into issues interacting with > > systemd's MemoryDenyWriteExecute feature. Currently for dynamically > > linked executables the kernel will only handle architecture specific > > properties like BTI for the interpreter, the expectation is that the > > interpreter will then handle any properties on the main executable. > > For BTI this means remapping the executable segments PROT_EXEC | > > PROT_BTI. > > > > This interacts poorly with MemoryDenyWriteExecute since that is > > implemented using a seccomp filter which prevents setting PROT_EXEC on > > already mapped memory and lacks the context to be able to detect that > > memory is already mapped with PROT_EXEC. This series resolves this by > > handling the BTI property for both the interpreter and the main > > executable. > > This appears to be a user-visible change which cannot be detected or > disabled from userspace. If there is code out there which does not work > when BTI is enabled, won't that now explode when the kernel enables it? > How are we supposed to handle such a regression? If this ever happens, the only workaround is to disable BTI on the kernel command line. If we need a knob closer to user, we could add a sysctl option (as we did for the tagged address ABI, though I doubt people are even aware that exists). The dynamic loader doesn't do anything smart when deciding to map objects with PROT_BTI (like env variables), it simply relies on the ELF information. I think that's very unlikely and feedback from Szabolcs in the past and additional testing by Mark and Jeremy was that it should be fine. The architecture allows interworking between BTI and non-BTI objects and on distros with both BTI and MDWE enabled, this is already the case: the main executable is mapped without PROT_BTI while the libraries will be mapped with PROT_BTI. The new behaviour allows both to be mapped with PROT_BTI, just as if MDWE was disabled. I think the only difference would be with a BTI-unware dynamic loader (e.g. older distro). Here the main executable, if compiled with BTI, would be mapped as executable while the rest of the libraries are non-BTI. The interworking should be fine but we can't test everything since such BTI binaries would not normally be part of the distro. If there are dodgy libraries out there that do tricks and branch into the middle of a function in the main executable, they will fail with this series but also fail if MDWE is disabled and the dynamic linker is BTI-aware. So this hardly counts as a use-case. For consistency, I think whoever does the initial mapping should also set the correct attributes as we do for static binaries. If you think another knob is needed other than the cmdline, I'm fine with it. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel