Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4259162yba; Wed, 17 Apr 2019 07:54:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqzrOKvBhZLgv8Fuk0oaxd4G6Xlo4AEEvyNa0+/vQuQKDwvToMgPe/wnoieE5kMRq4f18pmI X-Received: by 2002:a63:6941:: with SMTP id e62mr79632297pgc.99.1555512861793; Wed, 17 Apr 2019 07:54:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555512861; cv=none; d=google.com; s=arc-20160816; b=qS3czJsXi2nyv10p0euIXhedT4tDexc0IqSFF/dqcfZgrTabKCIOYzJ7yMAKbUwNet kySlwYqB49qXzNW72piAGzVt66pHeDUck+S9bDMwFqo6gdDm1057zEQFzXMTqNwVa5Zv BHy6BfJeDF2//rJd3E6AfuC/CtuWLEEExdcQVbs5wsjWqk04mc9HmKtIPkhbMprc+7P7 7qGeNDDLz2+yw8mHi+CrvGqWsQcZO60h/FG+SskyfTqIaJOcJUaSo9YhcBryECw23Xsk oxcTV+Dr0VYR1yANX6aLcr9Pdm8DfNr8HcZZ5yollVLM+b5VDkOvuoq/Cy/6s+5klLOu 3fTg== 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; bh=uQum97kQatN9Z2HMclYPQHOLq2S6+nuNyIFWCiG2pQk=; b=twz3xi25etWWOYwLUW2Y/MXYEfjlaxYfQ5FiF39Fg58mO/5JzTtSHRH21p/Zdupz+i STg0SypSFBU9FLtive31SYHD3Kp/ErH5uZjZ7r9EFw6uZCaU7b+SAgVggk+Hf0soH0Do iz9Wua6JabNVviaZ1s/CzH8RVmW1Yj4QsHqHUjOrlchYy4D+PnwQs0a3QtYWOQ4mLK9t orskKWq+2b3GfZmh002eOpiLLmt9pJDFVjhp2WPN+LiCFbEjjY7SMCInq+CKghDiuoT4 0kNFXH2bDKyorq8GatCFun79Llz16n3Z3OnQVpt4xnNGB3e0oR/QXasG5A2tbqMwj1lJ GhWQ== 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 h29si55367237pfd.180.2019.04.17.07.54.06; Wed, 17 Apr 2019 07:54:21 -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 S1732455AbfDQOxC (ORCPT + 99 others); Wed, 17 Apr 2019 10:53:02 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:46278 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730463AbfDQOxB (ORCPT ); Wed, 17 Apr 2019 10:53:01 -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 D8DC3A78; Wed, 17 Apr 2019 07:53:00 -0700 (PDT) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 395D63F557; Wed, 17 Apr 2019 07:52:59 -0700 (PDT) Date: Wed, 17 Apr 2019 15:52:56 +0100 From: Dave Martin To: Marc Zyngier Cc: Amit Daniel Kachhap , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Kristina Martsenko , kvmarm@lists.cs.columbia.edu, Ramana Radhakrishnan , linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 1/5] KVM: arm64: Add a vcpu flag to control ptrauth for guest Message-ID: <20190417145255.GB3567@e103592.cambridge.arm.com> References: <1555039236-10608-1-git-send-email-amit.kachhap@arm.com> <1555039236-10608-2-git-send-email-amit.kachhap@arm.com> <239c5d74-221e-cf8c-2c41-80db016bdc2b@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <239c5d74-221e-cf8c-2c41-80db016bdc2b@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 17, 2019 at 03:19:11PM +0100, Marc Zyngier wrote: > On 17/04/2019 14:08, Amit Daniel Kachhap wrote: > > Hi, > > > > On 4/17/19 2:05 PM, Marc Zyngier wrote: > >> On 12/04/2019 04:20, Amit Daniel Kachhap wrote: > >>> A per vcpu flag is added to check if pointer authentication is > >>> enabled for the vcpu or not. This flag may be enabled according to > >>> the necessary user policies and host capabilities. > >>> > >>> This patch also adds a helper to check the flag. > >>> > >>> Signed-off-by: Amit Daniel Kachhap > >>> Cc: Mark Rutland > >>> Cc: Marc Zyngier > >>> Cc: Christoffer Dall > >>> Cc: kvmarm@lists.cs.columbia.edu > >>> --- > >>> > >>> Changes since v8: > >>> * Added a new per vcpu flag which will store Pointer Authentication enable > >>> status instead of checking them again. [Dave Martin] > >>> > >>> arch/arm64/include/asm/kvm_host.h | 4 ++++ > >>> 1 file changed, 4 insertions(+) > >>> > >>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > >>> index 9d57cf8..31dbc7c 100644 > >>> --- a/arch/arm64/include/asm/kvm_host.h > >>> +++ b/arch/arm64/include/asm/kvm_host.h > >>> @@ -355,10 +355,14 @@ struct kvm_vcpu_arch { > >>> #define KVM_ARM64_HOST_SVE_ENABLED (1 << 4) /* SVE enabled for EL0 */ > >>> #define KVM_ARM64_GUEST_HAS_SVE (1 << 5) /* SVE exposed to guest */ > >>> #define KVM_ARM64_VCPU_SVE_FINALIZED (1 << 6) /* SVE config completed */ > >>> +#define KVM_ARM64_GUEST_HAS_PTRAUTH (1 << 7) /* PTRAUTH exposed to guest */ > >>> > >>> #define vcpu_has_sve(vcpu) (system_supports_sve() && \ > >>> ((vcpu)->arch.flags & KVM_ARM64_GUEST_HAS_SVE)) > >>> > >>> +#define vcpu_has_ptrauth(vcpu) \ > >>> + ((vcpu)->arch.flags & KVM_ARM64_GUEST_HAS_PTRAUTH) > >>> + > >> > >> Just as for SVE, please first check that the system has PTRAUTH. > >> Something like: > >> > >> (cpus_have_const_cap(ARM64_HAS_GENERIC_AUTH_ARCH) && \ > >> ((vcpu)->arch.flags & KVM_ARM64_GUEST_HAS_PTRAUTH)) > > > > In the subsequent patches, vcpu->arch.flags is only set to > > KVM_ARM64_GUEST_HAS_PTRAUTH when all host capability check conditions > > matches such as system_supports_address_auth(), > > system_supports_generic_auth() so doing them again is repetitive in my view. > > It isn't the setting of the flag I care about, but the check of that > flag. Checking a flag for a feature that cannot be used on the running > system should have a zero cost, which isn't the case here. > > Granted, the impact should be minimal and it looks like it mostly happen > on the slow path, but at the very least it would be consistent. So even > if you don't buy my argument about efficiency, please change it in the > name of consistency. One of the annoyances here is there is no single static key for ptrauth. I'm assuming we don't want to check both static keys (for address and generic auth) on hot paths. Checking just one of the two possibilities is OK for now, but we need to comment clearly somewhere that that will break if KVM is changed later to expose ptrauth to guests when the host doesn't support both types. Cheers ---Dave