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=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 A5749C433FE for ; Wed, 9 Dec 2020 10:52:37 +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 4705723B77 for ; Wed, 9 Dec 2020 10:52:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4705723B77 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=BMnPC/FwOoKBLf/AO8c1vOFfCfFiphQv3RwE7khuvC0=; b=JmYSnp9xd+qL1YKvfIQF8Xjuz kraGYCZFLK51TttTabtMwwdY8hEDeTdSHGoyKsIgdiaQrVb1jC9DpdYgayaub5MtIiQdHIC7rmyI5 aJOinvKhWVMYv/6BR88M0ETylqcbPNbEUtpd+nnze9LtiKQO6EBE5fku0peO0qvxLB39drsvw7r1N dyVrLRQsZgcnIostUSVKHdKbeKoyn0rQfO09w09obqRtwQFfEVCmVdxKVue+HCaaNLThIhQpsGMjJ A6kkiEcdGoSBvKtCdcCjg7aVJ7ymnkTa/TMQHj4gsXmM+A5byhVvXRfh7EoQCKb/8ZfevqSeRUr15 R6IYq0mFw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmx3x-0002FN-Gn; Wed, 09 Dec 2020 10:51:13 +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 1kmx3u-0002Ed-St for linux-arm-kernel@lists.infradead.org; Wed, 09 Dec 2020 10:51:12 +0000 Date: Wed, 9 Dec 2020 10:51:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607511068; bh=Ill3HBhRr4gyJsa20K49PnWajqnbQBBVEDpckvfkPrs=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=qPPP1kQbdk0npQOWsqwB8yYNGXO3pdhwq4u59pF26MHwSM6KNhYJ89boD+Gf9APWo VqA5OQJ8HabNBOWqQe+lnraxLhQmtv7aT0Ys+7W5bog9R3cCO7gsxxgLQeGpt3kSLZ WvKFWM6wCvpzyRXTJKchwMHAJTL0pdmME5tXXxOGZstGbCSWHg+e8ocnB2DFczfX3M ov0kcofa+B+V/BaDWeNzVhbl1pgtrZioVh8n2e/3Fowteq5ivxCPlk7tbWkJt8BJ2o gEdznWtz8PWecfpTKH8GojVS99amxJXQJZ0LDNQUrFcLhOIrP+FallOgqHt1rqCUCJ ftSss0PslDozA== From: Will Deacon To: Peter Collingbourne Subject: Re: [PATCH 2/2] arm64: Configure kernel's PTR_AUTH key when it is built with PTR_AUTH. Message-ID: <20201209105103.GA7273@willie-the-truck> References: <20201207224625.13764-1-daniel.kiss@arm.com> <20201207224625.13764-3-daniel.kiss@arm.com> <20201208110030.GA13960@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20201209_055111_065269_78B8A75A X-CRM114-Status: GOOD ( 33.13 ) 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: Catalin Marinas , Linux ARM , Daniel Kiss 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, Dec 08, 2020 at 11:33:33AM -0800, Peter Collingbourne wrote: > On Tue, Dec 8, 2020 at 3:00 AM Catalin Marinas wrote: > > > > On Mon, Dec 07, 2020 at 03:07:07PM -0800, Peter Collingbourne wrote: > > > On Mon, Dec 7, 2020 at 2:46 PM Daniel Kiss wrote: > > > > If the kernel is not compiled with CONFIG_ARM64_PTR_AUTH_KERNEL, > > > > then the kernel does not need a key and kernel's key could be disabled. > > > > > > > > Signed-off-by: Daniel Kiss > > > > --- > > > > arch/arm64/include/asm/asm_pointer_auth.h | 68 ++++++++++++++++------- > > > > arch/arm64/include/asm/processor.h | 2 + > > > > arch/arm64/kernel/asm-offsets.c | 4 ++ > > > > 3 files changed, 55 insertions(+), 19 deletions(-) > > > > > > > > diff --git a/arch/arm64/include/asm/asm_pointer_auth.h b/arch/arm64/include/asm/asm_pointer_auth.h > > > > index 52dead2a8640..af3d16027e8f 100644 > > > > --- a/arch/arm64/include/asm/asm_pointer_auth.h > > > > +++ b/arch/arm64/include/asm/asm_pointer_auth.h > > > > @@ -14,6 +14,12 @@ > > > > * thread.keys_user.ap*. > > > > */ > > > > .macro ptrauth_keys_install_user tsk, tmp1, tmp2, tmp3 > > > > +#ifndef CONFIG_ARM64_PTR_AUTH_KERNEL > > > > + /* Reenable A key */ > > > > + mrs \tmp1, sctlr_el1 > > > > + orr \tmp1, \tmp1, SCTLR_ELx_ENIA > > > > + msr sctlr_el1, \tmp1 > > > > +#endif > > > > > > We should avoid an unconditional MSR on exit like this as it is > > > expensive (for my PR_PAC_SET_ENABLED_KEYS series I measured the cost > > > of entry/exit MSR as 43.7ns on Cortex-A75 and 33.0ns on Apple M1). In > > > that series I take care not to touch SCTLR_EL1 unless necessary. > > > Likewise for the MSRs on entry below. > > > > I think that's how Daniel attempted the first (internal) version of > > these patches. In theory you don't need to touch SCTLR_ELx_EN* at all as > > long as the kernel does not use any PAC instructions. However, I was > > a bit concerned about this and thought it's safer if, when > > !CONFIG_ARM64_PTR_AUTH_KERNEL, the EnIA bit is cleared while in the > > kernel. > > > > If we can guarantee that the compiler does not generate any PAC > > instructions (it may assume they are no-ops) and vendor modules don't > > have such instructions either, we may be able to relax this. > > The way I see it it isn't too different from the current prohibition > on using IB in the kernel (and to a lesser extent DA/DB/GA since those > can't be accessed from nop-space as far as I'm aware), or NEON > instructions in most parts of the kernel, or the stack protector > cookie when building with -fno-stack-protector etc. i.e. if you do > that then you're breaking the ABI. > > Is your concern that distributions may default to enabling > -mbranch-protection which would result in the PAC instructions being > used? To address that I think it is reasonable to expect the compiler > not to use PAC instructions when passing -mbranch-protection=none, and > if the compiler does so then that is a bug in the compiler. I'm inclined to agree. At the very least, I think we should start from a position where we assume the compiler doesn't randomly emit these instructions, and then we can revisit that decision in future if it turns out to be wrong. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel