Received: by 10.192.165.148 with SMTP id m20csp509043imm; Fri, 27 Apr 2018 02:53:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoYeA2DEbuMlsDtBGDJbWv/bKxALpwYYbJUlUGO8rjqltWN0qzfK9xpTAzR9vC3BL5dU4NF X-Received: by 2002:a17:902:7c95:: with SMTP id y21-v6mr1690385pll.76.1524822831070; Fri, 27 Apr 2018 02:53:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524822831; cv=none; d=google.com; s=arc-20160816; b=DVhXCMs2lFl8UhhXOVvy8aCiUhg3Xe4FIde5lq0RK56UHW/++5dV9l/5AzsYCqFlbt tKq40wsW7SGna8a/iMABf6au/4acv5r508Dl90UqOvDe5OlQv/oyFXtcs5riukqeAtcq AZkgxE+MoY0FqZzyCBzq96vyEPtMzOIKMK6cCSkekEZ28uoKtHjlruZWVHCG9Ok/cMPL P3wmZuyT3oxL/nJ1M/PsrusSVyzTjXx/Sixcst5yTwpBOuJZpUjiZOxz5ozo8jhwGUgW W52+daxWT+HpVEYH5EdTnOYTSRz9tijB8GKaUMYE864O5iuELKJ83c+M6Nh7F3mOVRyX r5gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=2MjfCulBrV4pTZsJoyumoQ04d6D6hybe8s1QQ9+KkMk=; b=PBe5LYBpqlUbHPDRHUjl7LA0aTGdT1dzgkpLkhpG/r+0itHZqtnA/L5/0DZ4FUaRKF zDQS7rWgsLsrLI4XmAJ7ooumgaiGqfrJFUt8/v8u5lNqTAJjD94+3Lj/psb0S8qMPPMx D0RixfIa3+8SsZFCCOjyuEN6Z4PnQsmo1m+UfDh2Fccfcs3zjzx/P5LN2/v4vTcQ7BQs jDPKFjVkaT//7VG6nctXrzoH7+cuzmcV8/yzVWkKaXpWt7NuXMdZ/vhE9BYNU+Ovvc2K BXxT75I9zx1mNo+MdE8deHzhApXRDr1Dkn8U1k0F3qlflwwva3X+tqKuIrciSyDUS8Ce lmCQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1-v6si916013pld.424.2018.04.27.02.53.36; Fri, 27 Apr 2018 02:53:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932639AbeD0JwM (ORCPT + 99 others); Fri, 27 Apr 2018 05:52:12 -0400 Received: from foss.arm.com ([217.140.101.70]:37636 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757753AbeD0JwJ (ORCPT ); Fri, 27 Apr 2018 05:52:09 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BBEC9165D; Fri, 27 Apr 2018 02:52:08 -0700 (PDT) Received: from localhost (unknown [10.37.9.163]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 29C873F487; Fri, 27 Apr 2018 02:52:07 -0700 (PDT) Date: Fri, 27 Apr 2018 11:52:05 +0200 From: Christoffer Dall To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, arnd@arndb.de, marc.zyngier@arm.com, catalin.marinas@arm.com, awallis@codeaurora.org, kernel-hardening@lists.openwall.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, ramana.radhakrishnan@arm.com, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCHv3 04/11] arm64: Don't trap host pointer auth use to EL2 Message-ID: <20180427095205.GJ13249@C02W217FHV2R.local> References: <20180417183735.56985-1-mark.rutland@arm.com> <20180417183735.56985-5-mark.rutland@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180417183735.56985-5-mark.rutland@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 17, 2018 at 07:37:28PM +0100, Mark Rutland wrote: > To allow EL0 (and/or EL1) to use pointer authentication functionality, > we must ensure that pointer authentication instructions and accesses to > pointer authentication keys are not trapped to EL2. > > This patch ensures that HCR_EL2 is configured appropriately when the > kernel is booted at EL2. For non-VHE kernels we set HCR_EL2.{API,APK}, > ensuring that EL1 can access keys and permit EL0 use of instructions. > For VHE kernels host EL0 (TGE && E2H) is unaffected by these settings, > and it doesn't matter how we configure HCR_EL2.{API,APK}, so we don't > bother setting them. > > This does not enable support for KVM guests, since KVM manages HCR_EL2 > itself when running VMs. > > Signed-off-by: Mark Rutland > Cc: Christoffer Dall > Cc: Catalin Marinas > Cc: Marc Zyngier > Cc: Will Deacon > Cc: kvmarm@lists.cs.columbia.edu FWIW: Acked-by: Christoffer Dall > --- > arch/arm64/include/asm/kvm_arm.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h > index 89b3dda7e3cb..4d57e1e58323 100644 > --- a/arch/arm64/include/asm/kvm_arm.h > +++ b/arch/arm64/include/asm/kvm_arm.h > @@ -23,6 +23,8 @@ > #include > > /* Hyp Configuration Register (HCR) bits */ > +#define HCR_API (UL(1) << 41) > +#define HCR_APK (UL(1) << 40) > #define HCR_TEA (UL(1) << 37) > #define HCR_TERR (UL(1) << 36) > #define HCR_TLOR (UL(1) << 35) > @@ -86,7 +88,7 @@ > HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW | HCR_TLOR | \ > HCR_FMO | HCR_IMO) > #define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF) > -#define HCR_HOST_NVHE_FLAGS (HCR_RW) > +#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK) > #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H) > > /* TCR_EL2 Registers bits */ > -- > 2.11.0 > > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm