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 48F40C433EF for ; Thu, 21 Apr 2022 09:34:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356019AbiDUJhE (ORCPT ); Thu, 21 Apr 2022 05:37:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344421AbiDUJhD (ORCPT ); Thu, 21 Apr 2022 05:37:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E83F1DA7A for ; Thu, 21 Apr 2022 02:34:14 -0700 (PDT) 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 DD72D6179B for ; Thu, 21 Apr 2022 09:34:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3957BC385A1; Thu, 21 Apr 2022 09:34:11 +0000 (UTC) Date: Thu, 21 Apr 2022 10:34:07 +0100 From: Catalin Marinas To: Jeremy Linton Cc: Mark Brown , Will Deacon , Kees Cook , linux-arm-kernel@lists.infradead.org, hjl.tools@gmail.com, libc-alpha@sourceware.org, szabolcs.nagy@arm.com, yu-cheng.yu@intel.com, ebiederm@xmission.com, linux-arch@vger.kernel.org Subject: Re: [PATCH v13 0/2] arm64: Enable BTI for the executable as well as the interpreter Message-ID: References: <20220419105156.347168-1-broonie@kernel.org> <165043278356.1481705.13924459838445776007.b4-ty@chromium.org> <20220420093612.GB6954@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Wed, Apr 20, 2022 at 08:39:14AM -0500, Jeremy Linton wrote: > On 4/20/22 06:57, Mark Brown wrote: > > On Wed, Apr 20, 2022 at 10:57:30AM +0100, Catalin Marinas wrote: > > > On Wed, Apr 20, 2022 at 10:36:13AM +0100, Will Deacon wrote: > > > > Kees, please can you drop this series while Catalin's alternative solution > > > > is under discussion (his Reviewed-by preceded the other patches)? > > > > > > https://lore.kernel.org/r/20220413134946.2732468-1-catalin.marinas@arm.com > > > > > > Both series expose new behaviours to userspace and we don't need both. [...] > > > Arguably, the two approaches are complementary but the way this series > > > turned out is for the BTI on main executable to be default off. I have a > > > worry that the feature won't get used, so we just carry unnecessary code > > > in the kernel. Jeremy also found this approach less than ideal: > > > > > https://lore.kernel.org/r/59fc8a58-5013-606b-f544-8277cda18e50@arm.com > > > > I'm not sure there was a fundamental concern with the approach there but > > rather some pushback on the instance on turning it off by default. > > Right, this one seems to have the smallest impact on systemd as it exists > today. It had a bigger impact on glibc which had to rework the dynamic library mapping to use munmap/mmap() instead of an mprotect() (though that's already done). I think glibc still prefers the mprotect() approach for dynamic libraries. > I would have expected the default to be on, because IMHO this set > corrects what at first glance just looks like a small oversight. This was a design decision at the time, maybe not the best but it gives us some flexibility (and we haven't thought of MDWE). > I find the ABI questions a bit theoretical, given that this should > only affect environments that don't exist outside of labs/development > orgs at this point (aka systemd services on HW that implements BTI). The worry is not what breaks now but rather what happens when today's distros will eventually be deployed on large-scale BTI-capable hardware. It's a very small risk but non-zero. The idea is that if we come across some weird problem, a fixed-up dynamic loader could avoid enabling BTI on a per-process basis without the need to do this at the system level. Personally I'm fine with this risk. Will is not and I respect his position, hence I started the other thread to come up with a MDWE alternative. > The other approach works, and if the systemd folks are on board with it also > should solve the underlying problem, but it creates a bit of a compatibility > problem with existing containers/etc that might exist today (although > running systemd/services in a container is itself a discussion). > > So, frankly, I don't see why they aren't complementary. They are complementary, though if we change the MDWE approach, there's less of a need for this patchset. -- 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 92D31C433F5 for ; Thu, 21 Apr 2022 09:35:18 +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=DXp1M3ClCyhoPcLtuMk6cV5zxmZLcnihuHsRznByhpM=; b=uyDOHTUfUIzlTt n7dk4AzxamfSQIvBvw4Og+OEmMizUSW2EurGyKnQ1C6SKWeBfR7vZ8YcU7e4IXbXzGcJazeHW6DZe witqiclYY9gbx3N12c1m9+KK6RR3iEs02a8W2hTnfkbxM2mx/8oyYZ7zyKT2r9X4moXp/0VMtUAq7 aILaCmGw89VVDBKDyxUZ1KFb9yziFEgnVAZP+1+b4QOarzocgcWILnB1umdsUl2DRPaGd0+m39Epp h3mPcBGt7vRj2WvOW2SdqkSNz/Oaq3NxmNihdzP3BTWPGoEYUfxVbx7X+ZXs1W13pu00RFBSxg78Y BX4z6EeNS7c95rJQyHog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhTCe-00CmL4-Fn; Thu, 21 Apr 2022 09:34:20 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhTCa-00CmIs-DP for linux-arm-kernel@lists.infradead.org; Thu, 21 Apr 2022 09:34:18 +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 9ACA7B82391; Thu, 21 Apr 2022 09:34:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3957BC385A1; Thu, 21 Apr 2022 09:34:11 +0000 (UTC) Date: Thu, 21 Apr 2022 10:34:07 +0100 From: Catalin Marinas To: Jeremy Linton Cc: Mark Brown , Will Deacon , Kees Cook , linux-arm-kernel@lists.infradead.org, hjl.tools@gmail.com, libc-alpha@sourceware.org, szabolcs.nagy@arm.com, yu-cheng.yu@intel.com, ebiederm@xmission.com, linux-arch@vger.kernel.org Subject: Re: [PATCH v13 0/2] arm64: Enable BTI for the executable as well as the interpreter Message-ID: References: <20220419105156.347168-1-broonie@kernel.org> <165043278356.1481705.13924459838445776007.b4-ty@chromium.org> <20220420093612.GB6954@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220421_023416_795751_0CD15D0E X-CRM114-Status: GOOD ( 28.36 ) 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 Wed, Apr 20, 2022 at 08:39:14AM -0500, Jeremy Linton wrote: > On 4/20/22 06:57, Mark Brown wrote: > > On Wed, Apr 20, 2022 at 10:57:30AM +0100, Catalin Marinas wrote: > > > On Wed, Apr 20, 2022 at 10:36:13AM +0100, Will Deacon wrote: > > > > Kees, please can you drop this series while Catalin's alternative solution > > > > is under discussion (his Reviewed-by preceded the other patches)? > > > > > > https://lore.kernel.org/r/20220413134946.2732468-1-catalin.marinas@arm.com > > > > > > Both series expose new behaviours to userspace and we don't need both. [...] > > > Arguably, the two approaches are complementary but the way this series > > > turned out is for the BTI on main executable to be default off. I have a > > > worry that the feature won't get used, so we just carry unnecessary code > > > in the kernel. Jeremy also found this approach less than ideal: > > > > > https://lore.kernel.org/r/59fc8a58-5013-606b-f544-8277cda18e50@arm.com > > > > I'm not sure there was a fundamental concern with the approach there but > > rather some pushback on the instance on turning it off by default. > > Right, this one seems to have the smallest impact on systemd as it exists > today. It had a bigger impact on glibc which had to rework the dynamic library mapping to use munmap/mmap() instead of an mprotect() (though that's already done). I think glibc still prefers the mprotect() approach for dynamic libraries. > I would have expected the default to be on, because IMHO this set > corrects what at first glance just looks like a small oversight. This was a design decision at the time, maybe not the best but it gives us some flexibility (and we haven't thought of MDWE). > I find the ABI questions a bit theoretical, given that this should > only affect environments that don't exist outside of labs/development > orgs at this point (aka systemd services on HW that implements BTI). The worry is not what breaks now but rather what happens when today's distros will eventually be deployed on large-scale BTI-capable hardware. It's a very small risk but non-zero. The idea is that if we come across some weird problem, a fixed-up dynamic loader could avoid enabling BTI on a per-process basis without the need to do this at the system level. Personally I'm fine with this risk. Will is not and I respect his position, hence I started the other thread to come up with a MDWE alternative. > The other approach works, and if the systemd folks are on board with it also > should solve the underlying problem, but it creates a bit of a compatibility > problem with existing containers/etc that might exist today (although > running systemd/services in a container is itself a discussion). > > So, frankly, I don't see why they aren't complementary. They are complementary, though if we change the MDWE approach, there's less of a need for this patchset. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel