Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4388485yba; Wed, 17 Apr 2019 10:23:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwVotMUGkFQlkeQWXsH6v3feQ9OpA49jn/MkyBOEygH94R/5gV+znUwcJg9dhBU2id4ZxpY X-Received: by 2002:a65:4482:: with SMTP id l2mr628444pgq.362.1555521798371; Wed, 17 Apr 2019 10:23:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555521798; cv=none; d=google.com; s=arc-20160816; b=UOLucrwq5RbqDl2O1/ra4xisIsuM5GkFH7M5urMXPWNjyVnSs3vt9jmGPwsj28vBvc Q9EthVt46YAAJFIUk4PiLdXf0c7B5c176mkg7Qb0QZjlexe9JKspLGmUpPHe2ImMysRH qd9SYJYAbYg4UTzkYXv7+xbF6DUOKb1D21sFMZEEWFF91fPM0aLS42dp3Wgn8AvCMJ7z VDxWVcsyYdH7NPUh3D97cs1Dr0db5UUMt6nLa8y8N4BQscwwppXK7SziKDGQt6KUbnEo lBJtYMQZH9u2it6a/tLvQfDMvI/1GYOjlx1gPV/Ufdt+jpBzlJzyifqns9q/OK2CZwjW kB+Q== 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=2ixOtV8+7+OTw4P0lbuqCFQzvEzp86I8YzXuEkrpAFI=; b=n/Tdpy15gRyO/a4UEV4rtt5y9E3J8LdnAxTDunn0j5QUz+yPhfeSNrAV8N4tN2LbBi v8ZL67OHM+PZ6qgYWOd/4fHlVzkmVY8WBy0eExNUqJViB2TlIqRHLDnZ0ffW+bcfej3v 69OJNxarj+BiprHuGog6H6qXxnn7XXZwBEY09OIxQjj/WLDgiuMUQXEnHbWZuFi8P2IU T6kgskb6SoxlaHXlP8OqXOEbVxeGx1wRqK3Ackva7bapP6MWUfUdslmHeG9GV7RrpTUY B5NjBviiAR0BBJ6qI5cAI6zhMFmruQhyVJtOkhYc55q7sKcjM2VEXqEt7Fo5trueICwo eEJw== 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 q13si51628248pff.3.2019.04.17.10.23.02; Wed, 17 Apr 2019 10:23:18 -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 S1733032AbfDQRUQ (ORCPT + 99 others); Wed, 17 Apr 2019 13:20:16 -0400 Received: from foss.arm.com ([217.140.101.70]:48468 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729395AbfDQRUP (ORCPT ); Wed, 17 Apr 2019 13:20:15 -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 4D6D715AB; Wed, 17 Apr 2019 10:20:15 -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 A21743F59C; Wed, 17 Apr 2019 10:20:13 -0700 (PDT) Date: Wed, 17 Apr 2019 18:20:11 +0100 From: Dave Martin To: Marc Zyngier Cc: Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, Kristina Martsenko , Ramana Radhakrishnan , Amit Daniel Kachhap , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v9 1/5] KVM: arm64: Add a vcpu flag to control ptrauth for guest Message-ID: <20190417172010.GE3567@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> <20190417145255.GB3567@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 04:54:32PM +0100, Marc Zyngier wrote: > On 17/04/2019 15:52, Dave Martin wrote: > > 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. > > They both just branches, so I don't see why not. Of course, for people > using a lesser compiler (gcc 4.8 or clang), things will suck. But they > got it coming anyway. I seem to recall Christoffer expressing concerns about this at some point: even unconditional branches branches to a fixed address are not free (or even correctly predicted). I don't think any compiler can elide static key checks of merge them together. Maybe I am misremembering. Cheers ---Dave