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=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 745F4C433E0 for ; Thu, 9 Jul 2020 14:36:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 3EB342073A for ; Thu, 9 Jul 2020 14:36:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="C4QqMNnk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3EB342073A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ynuarwVSZf6l6er82Uvg+N064C98Gw7U4naQ5SoNrHM=; b=C4QqMNnkEDWtn6oJL1gDTgf+p jkhKDrB+hhl2xeVluH+77lqZX2l9UuLz56ONiBtk37y7C44w+Hl0nOVqjFlHTyYdKH2+Mg7Y0aK2W P9v4S+WK5uqePM7BFuudtMYdZqR4J53ohR6F6P/7kGSA10ITdwcGKagJYKYjykThe6kQ+QWkbPVVp I0/sjaJEDVr3NoH90Ce2wy/HVzXFgDUu9fBk3irSrSLHTFo49H21xIQt3k/3XDIT3RA4Rie4f60Y3 jAGziZ32CWvEuGSr6F2FFL8iqyygad6+nacfUjBRwWBcV4Tgl/gZfXAuJ3yqNk+flqWolcgzFgCgb X4PzgTILw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtXdV-00023R-5M; Thu, 09 Jul 2020 14:34:53 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtXdS-000235-LC for linux-arm-kernel@lists.infradead.org; Thu, 09 Jul 2020 14:34:51 +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 5792931B; Thu, 9 Jul 2020 07:34:43 -0700 (PDT) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 193D83F792; Thu, 9 Jul 2020 07:34:43 -0700 (PDT) Subject: Re: [PATCH] arm64: Introduce sysctl to disable pointer authentication To: Will Deacon , Steve Capper References: <20200707173232.5535-1-steve.capper@arm.com> <20200708073621.GA25261@willie-the-truck> <20200708134650.GA27102@capper-ampere.manchester.arm.com> <20200708220805.GB27130@willie-the-truck> From: Jeremy Linton Message-ID: <622ed9ab-fa49-3885-e7c3-66cb8821fe81@arm.com> Date: Thu, 9 Jul 2020 09:34:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200708220805.GB27130@willie-the-truck> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200709_103450_830083_5EF4A796 X-CRM114-Status: GOOD ( 33.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, catalin.marinas@arm.com, nd@arm.com, linux-arm-kernel@lists.infradead.org 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 7/8/20 5:08 PM, Will Deacon wrote: > Hi Steve, > > On Wed, Jul 08, 2020 at 02:46:52PM +0100, Steve Capper wrote: >> On Wed, Jul 08, 2020 at 08:36:21AM +0100, Will Deacon wrote: >>> On Tue, Jul 07, 2020 at 06:32:32PM +0100, Steve Capper wrote: >>>> Pointer authentication is a mandatory feature in the Armv8.3 >>>> architecture that provides protection against return oriented >>>> programming attacks. (meaning that all Arm CPUs targetting at least >>>> Armv8.3 will have this feature). >>>> >>>> Once CONFIG_ARM64_PTR_AUTH=y, any systems with the hardware support for >>>> pointer authentication will automatically have it enabled by the kernel. >>>> >>>> There are, however, situations where end users may want to disable >>>> pointer authentication. One could be tracking down/working around a bug >>>> in userspace relating to pointer auth. Also, one may wish to quantify >>>> the performance overhead of pointer auth by running a workload >>>> with/without it. >>> >>> If you're debugging userspace, just recompile your userspace application >>> without ptr auth, in the same way that you might recompile with -g >>> >>> The performance argument sucks; this stuff needs to be fast otherwise it's >>> pointless. If you really need that last bit of speed, try Gentoo ;) >> >> I've tried Gentoo, and I liked it :-). > > In fact, I used to use it as well but it's a total bugger if you forget > to update for a week or so. I remember an awful program called revdep-rebuild > or something. Dreadful stuff, but good fun (and, incidentally, what got me > interested in the kernel). > >> Apologies, I could have done a better job with the commit log... > > I've got to be honest, but the commit log smells of "I'm doing this because > somebody asked me to, not because I think it's a good idea"... Maybe I'm > wrong. > >> I am trying to enable pointer authentication in distros. One concern I have >> is that a pointer auth bug could slip through the cracks (with a lot of >> hardware not yet supporting pointer auth), and then affect an end user. > > Why is that different to any other feature we expose to userspace? Bugs > happen, and we deal with them. > >> Also, I have had interest from distros in the performance cost of pointer >> auth, and there will very likely be folk switching it off/on again in >> order to perform tests. > > And they can do that with the compiler at the same time as they pass > -funsafe-math -Ofast. So, a bit of background. Pointer auth has been accepted as a systemwide change for Fedora 33. That acceptance requires contingency planning for what to do if the feature is causing ship blocking/etc defects. While we are going to do our best to test it before release, as your aware, the 8.3+ machines are in short supply. Most of the community testing & debugging will simply be to assure that we don't break anything on v8.0 machines. Which means that its quite likely that the bugs are going to be reported by end users with 8.3+ hardware who don't compile their own packages, nor debug them (and the idea that we can get any kind of coverage on tens of thousands of packages is crazy). Given many of the bugs so far have been subtle glibc/gcc/etc they are also far ranging. So, being able to give the end user a simple way to a->b test whether a problem goes away helps us to triage whether we are looking at a generic bug, or one related to pointer auth (or for that matter an active attack). Further, should it happen to something during the boot process (which is significantly more complex on fedora than the usual kernel+busybox+disk image) then we need a straightforward method to boot the end users machines so they can in-place install/upgrade/test. In summary I see this sort of similar to selinux=0, a flag that no one should be using, but is still frequently used because its required just to boot a machine in order to fix a problem. > >> One approach to deploying this could be to have pointer auth disabled in >> the kernel completely (via kconfig) and interested parties could then >> switch kernels. Trouble with this is that distros ship single binaries so >> it would be up to the end user to build/install another kernel + modules. >> So this could be a barrier to adoption. > > Shipping multiple kernels is a non-starter, but I fail to see why that > is even a consideration given that this really isn't a kernel problem > afaict. We need a way to ship all the PAC enabled binary artifacts but assure they can be quickly/easily reverted to pre 8.3 pointer auth code paths, which have been more heavily tested. Rebuilding the entire distro to globally disable pointer auth is a non starter, particularly after it has shipped. > >> Having a mechanism in the kernel that an end user can employ to activate/ >> de-activate pointer auth would help with deployment greatly, and that is >> what I was trying to achieve with this patch. >> >> Another way to approach this could be via a kernel command line that >> completely disables pointer auth? (i.e. kernel not activating pointer auth >> at all, and userspace not seeing the feature) > > I did wonder briefly about overriding the sanitised ID registers on the > command-line, but I think it opens a door that we'll regret opening later > on. > > Will > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel