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=-5.5 required=3.0 tests=BAYES_00,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 43D5AC433E4 for ; Tue, 14 Jul 2020 17:53:52 +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 1221C2256C for ; Tue, 14 Jul 2020 17:53:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UEWqscDz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1221C2256C 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=kgtITKKvt9NNO4cSXOVvMkaXSiftbZFIcr0BufGAs8g=; b=UEWqscDzYoIUfUOuer8jSXsSx Va2JNfwozVDFojM/XMRC9FHgmcxLEmnniwRlR0KFmKziEqeN4G9NJtNUX6oeVASfgNdRv8ibqnpxj rKqUvi1OTlAyCsookyYSpWOAd7pmaveV91m6RM3OgTPhQb1Cf+GDKZODKr9GF61wMOUOkuLC69YV3 TkOLBtN++UMt8NmM7lrGlYscf1OKV9wwRYlnQ+oyvKZFXZ5yUmH39Y/GK+KIUTWmFRvkPAMOT7Wv7 Wj49hqdGLxN5VvmIenFQCeUqS1lDRjOfXgKTVJEIFfXRMrWznls9rJxPqr/BcMnHZl6HzDMxwiPzG qhIS827aw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvP6M-0001wn-Sh; Tue, 14 Jul 2020 17:52:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvP6K-0001wS-MQ for linux-arm-kernel@lists.infradead.org; Tue, 14 Jul 2020 17:52:21 +0000 Received: from gaia (unknown [95.146.230.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D97C32256C; Tue, 14 Jul 2020 17:52:18 +0000 (UTC) Date: Tue, 14 Jul 2020 18:52:16 +0100 From: Catalin Marinas To: Will Deacon Subject: Re: [PATCH] arm64: Introduce sysctl to disable pointer authentication Message-ID: <20200714175215.GB10736@gaia> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200708220805.GB27130@willie-the-truck> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200714_135220_806838_2D30A701 X-CRM114-Status: GOOD ( 24.33 ) 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, nd@arm.com, jeremy.linton@arm.com, linux-arm-kernel@lists.infradead.org, Steve Capper 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, Jul 08, 2020 at 11:08:06PM +0100, Will Deacon wrote: > 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. [...] > > 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. I had attempted it in these two patches (together with the DT support): https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-24-catalin.marinas@arm.com/ https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-25-catalin.marinas@arm.com/ (both patches now dropped; we have a way to disable the tagged addr ABI already and reject the prctl() call) Overriding the ID regs disables the feature for both user and kernel. IIUC, Steve only wanted this disabled for user. A light concern with this patch is that it still keeps the HWCAP around, only that it makes this instructions behave as NOPs. So that would be a deviation from what the HWCAP bit actually implies. From this perspective, a big knob may be a cleaner option. Anyway, I agree that opening the door would lead to more such requests in the future. We should only do this if there is a high risk of the feature going terribly wrong in the user space out there. AFAICT, that's not entirely clear at the moment. Distros could carry such patch temporarily and, if proven useful in the long run, we can revisit the upstreaming story. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel