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 5EF35C433F5 for ; Wed, 20 Apr 2022 13:39:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233121AbiDTNmR (ORCPT ); Wed, 20 Apr 2022 09:42:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378590AbiDTNmQ (ORCPT ); Wed, 20 Apr 2022 09:42:16 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C6B774338F for ; Wed, 20 Apr 2022 06:39:29 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 899AA23A; Wed, 20 Apr 2022 06:39:29 -0700 (PDT) Received: from [192.168.122.164] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 388FF3F5A1; Wed, 20 Apr 2022 06:39:29 -0700 (PDT) Message-ID: Date: Wed, 20 Apr 2022 08:39:14 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v13 0/2] arm64: Enable BTI for the executable as well as the interpreter Content-Language: en-US To: Mark Brown , Catalin Marinas Cc: 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 References: <20220419105156.347168-1-broonie@kernel.org> <165043278356.1481705.13924459838445776007.b4-ty@chromium.org> <20220420093612.GB6954@willie-the-truck> From: Jeremy Linton In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org Hi, 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. > >> I agree. Even though the patches have my reviewed-by, I think we should >> postpone them until we figure out a better W^X solution that does not >> affect BTI (and if we can't, we revisit these patches). > > Indeed. I had been expecting this to follow the pattern of the previous > nine months or so and be mostly ignored for the time being while > Catalin's new series goes forward. Now that it's applied it might be > worth keeping the first patch still in case someone else needs it but > the second patch can probably wait. > >> 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. I would have expected the default to be on, because IMHO this set corrects what at first glance just looks like a small oversight. 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 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. This fixes a bug we have today, the other set creates a generic mechanism for the future. Thanks, 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 D65D5C433F5 for ; Wed, 20 Apr 2022 13:40:40 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/AsHnrQgRCpWW2MgdKIOoK9rpNT7lAe6z7xQ45uujQg=; b=gNHIc2g4Wnt6yy UzmYpay92VkJOGF1xNKZ3NMyqGm/nrmMbHjVWQIBCN5P91UeSJQL0p59+3taZsSmJd497bNmA364H O/AuJAN32fSCoWWylsXpAc9ruYxQGOt3KNxTKWiLvevEDpmWlwEVV46TmnJFVx4K35Z0+b11DzE/a Nzi+4Nw8cceFjZ41i8D+2AeGKfirjjAZ67kOeyd1SKv4AP0mT86p/AJCYBDDLsiEE684BxIpVRJKl pjEMNIKTJno2yGrpV5oKovhGNKetYcRbIMKFqv4zplOM95H1oA+PEHxuTi0uYmAz7CXSAsiwMBh83 zt4tr9wG7M8KdQCQ1Gcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhAYV-009Gik-Iu; Wed, 20 Apr 2022 13:39:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhAYS-009Ghi-7W for linux-arm-kernel@lists.infradead.org; Wed, 20 Apr 2022 13:39:38 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 899AA23A; Wed, 20 Apr 2022 06:39:29 -0700 (PDT) Received: from [192.168.122.164] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 388FF3F5A1; Wed, 20 Apr 2022 06:39:29 -0700 (PDT) Message-ID: Date: Wed, 20 Apr 2022 08:39:14 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v13 0/2] arm64: Enable BTI for the executable as well as the interpreter Content-Language: en-US To: Mark Brown , Catalin Marinas Cc: 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 References: <20220419105156.347168-1-broonie@kernel.org> <165043278356.1481705.13924459838445776007.b4-ty@chromium.org> <20220420093612.GB6954@willie-the-truck> From: Jeremy Linton In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220420_063936_342939_D8DA9A2E X-CRM114-Status: GOOD ( 23.56 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, 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. > >> I agree. Even though the patches have my reviewed-by, I think we should >> postpone them until we figure out a better W^X solution that does not >> affect BTI (and if we can't, we revisit these patches). > > Indeed. I had been expecting this to follow the pattern of the previous > nine months or so and be mostly ignored for the time being while > Catalin's new series goes forward. Now that it's applied it might be > worth keeping the first patch still in case someone else needs it but > the second patch can probably wait. > >> 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. I would have expected the default to be on, because IMHO this set corrects what at first glance just looks like a small oversight. 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 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. This fixes a bug we have today, the other set creates a generic mechanism for the future. Thanks, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel