Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp153381yba; Fri, 5 Apr 2019 04:05:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqxX6EqgQHd/8CaGqM144x547YPZKo+6DYmgvpW8jbG+SVuFVIPIfTk5R58HnvVJjUOHpp5x X-Received: by 2002:a17:902:822:: with SMTP id 31mr12470671plk.290.1554462357991; Fri, 05 Apr 2019 04:05:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554462357; cv=none; d=google.com; s=arc-20160816; b=u9lxuHAv2hLDuG+uPhAYDK0RdqVImDo/bNoaTJI3+aDh5NIP9k+U0qEEAg+z5QSjw9 EpPwgJXrHkF5pCyiVjC35f5agkIKnoew3toqUwNSUvKOJKjCa+VGKKJ9Sohfmfn5g6sC pTyleF5BXNJw24wi/jgfnlC7zYaMbnMu5hSZhVn7NXjAfrV17f72w7uapNRcJG+jZwEx lqooAIb/jB1L/5Y63wTUqwoVnAIxNfdMwroYqrTOk71lID8Ku9jAFdwX54mB42AEQQcr 79vZoT8PkbwifddF6fJGYJ6q0S0ixizZDHFezruBkPGU49ezMKxUZ2Flyl413nFe1S8w c7IA== 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=lQF7a9Vyr81ezeUHw4k95TK7iTJ8DdT+FhjXjCTUEdU=; b=swcDMsFxngNMPPFYXbm7BjIPO122Ys9LShVHPFvz9rA0QKM8/028UFNf/xkmdrqf2f J43ds+b6U1UzuKv/cs2whyC6iOS8outdIwYL5fpqgMYPo74xJQZKpI8JkZlweILOjk7h a+GAIeI0+kL7yKd52YWFuZEgW+7PmmoU3lodxX70BoI2bRXpXgCMfmK5UetmWjjg3Yai 9BDf1E+/rdctmWeRL7/oYt1DZFAkxqmofLPftKuo+zur85c4O3qSlz7AgrcgBy0cmhvD ZDUYDzsBGW8dtXF+e/mQX/dxpzihbZZdlNy1u6EpTsii9/whdUHfkd+Wgz94RArE2IvL HSnw== 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 x4si18680100plo.203.2019.04.05.04.05.42; Fri, 05 Apr 2019 04:05:57 -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 S1731000AbfDELDp (ORCPT + 99 others); Fri, 5 Apr 2019 07:03:45 -0400 Received: from foss.arm.com ([217.140.101.70]:46096 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730497AbfDELDo (ORCPT ); Fri, 5 Apr 2019 07:03:44 -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 E81C0168F; Fri, 5 Apr 2019 04:03:43 -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 2746A3F557; Fri, 5 Apr 2019 04:03:42 -0700 (PDT) Date: Fri, 5 Apr 2019 12:03:39 +0100 From: Dave Martin To: Amit Daniel Kachhap Cc: linux-arm-kernel@lists.infradead.org, Marc Zyngier , Catalin Marinas , Will Deacon , Kristina Martsenko , kvmarm@lists.cs.columbia.edu, Ramana Radhakrishnan , linux-kernel@vger.kernel.org, Mark Rutland Subject: Re: [PATCH v8 8/9] KVM: arm64: Add capability to advertise ptrauth for guest Message-ID: <20190405110339.GU3567@e103592.cambridge.arm.com> References: <1554172037-4516-1-git-send-email-amit.kachhap@arm.com> <1554172037-4516-9-git-send-email-amit.kachhap@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1554172037-4516-9-git-send-email-amit.kachhap@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 Tue, Apr 02, 2019 at 07:57:16AM +0530, Amit Daniel Kachhap wrote: > This patch advertises the capability of two cpu feature called address > pointer authentication and generic pointer authentication. These > capabilities depend upon system support for pointer authentication and > VHE mode. > > The current arm64 KVM partially implements pointer authentication and > support of address/generic authentication are tied together. However, > separate ABI requirements for both of them is added so that the future > isolated implementation will not require any ABI changes. > > Signed-off-by: Amit Daniel Kachhap > Cc: Mark Rutland > Cc: Marc Zyngier > Cc: Christoffer Dall > Cc: kvmarm@lists.cs.columbia.edu > --- > > Changes since v7: > * Created 2 capabilities KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC > instead of one KVM_CAP_ARM_PTRAUTH [Kristina Martsenko]. > * Added documentation here itself instead of in a new patch. > > Documentation/virtual/kvm/api.txt | 3 +++ > arch/arm64/kvm/reset.c | 6 ++++++ > include/uapi/linux/kvm.h | 2 ++ > 3 files changed, 11 insertions(+) > > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index aaa048d..9b56892 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -2661,8 +2661,11 @@ Possible features: > Depends on KVM_CAP_ARM_PMU_V3. > - KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication > for the CPU and supported only on arm64 architecture. > + Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS. > - KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication > for the CPU and supported only on arm64 architecture. > + Depends on KVM_CAP_ARM_PTRAUTH_GENERIC. > > > 4.83 KVM_ARM_PREFERRED_TARGET > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 717afed..8aa8982 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -92,6 +92,12 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ARM_VM_IPA_SIZE: > r = kvm_ipa_limit; > break; > + case KVM_CAP_ARM_PTRAUTH_ADDRESS: > + r = has_vhe() && system_supports_address_auth(); > + break; > + case KVM_CAP_ARM_PTRAUTH_GENERIC: > + r = has_vhe() && system_supports_generic_auth(); > + break; If some hardware supports just one auth type, we would report just one of these caps. Although we have the rule that userspace is not allowed to request these independently in KVM_ARM_VCPU_INIT anyway, I think it would be easier for userspace if we suppress both caps if either auth type isn't available on the host. e.g.: case KVM_ARM_ARM_PTRAUTH_ADDRESS: case KVM_ARM_ARM_PTRAUTH_GENERIC: r = has_vhe() && system_supports_address_auth() && system_supports_generic_auth(); We could revert back to the above code later on, and apply the ABI relaxations described in my response to the vcpu features patch, if someday we add support to KVM for coping with host hardware that supports just one auth type. I'd like Mark to comment on this, since he's more aware of the architectural situation than I am. Cheers ---Dave