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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS 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 9A94CC43381 for ; Wed, 20 Mar 2019 18:07:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7AD78218A5 for ; Wed, 20 Mar 2019 18:07:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727380AbfCTSHA (ORCPT ); Wed, 20 Mar 2019 14:07:00 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:44270 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726438AbfCTSG7 (ORCPT ); Wed, 20 Mar 2019 14:06:59 -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 09CF8A78; Wed, 20 Mar 2019 11:06:59 -0700 (PDT) Received: from [10.1.197.45] (e112298-lin.cambridge.arm.com [10.1.197.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8CC453F614; Wed, 20 Mar 2019 11:06:55 -0700 (PDT) Subject: Re: [PATCH v7 9/10] KVM: arm64: docs: document KVM support of pointer authentication To: Kristina Martsenko , Amit Daniel Kachhap , linux-arm-kernel@lists.infradead.org Cc: Christoffer Dall , Marc Zyngier , Catalin Marinas , Will Deacon , Andrew Jones , Dave Martin , Ramana Radhakrishnan , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, Mark Rutland , James Morse References: <1552984243-7689-1-git-send-email-amit.kachhap@arm.com> <1552984243-7689-10-git-send-email-amit.kachhap@arm.com> <7bf19035-02ba-ae47-b08c-7d7622a45dbf@arm.com> <648d66dd-519c-7567-a3e1-c23208f68cf2@arm.com> From: Julien Thierry Message-ID: <52d3f9c8-fc27-bf3d-f8f3-1b3921508a8c@arm.com> Date: Wed, 20 Mar 2019 18:06:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <648d66dd-519c-7567-a3e1-c23208f68cf2@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/03/2019 15:04, Kristina Martsenko wrote: > On 20/03/2019 13:37, Julien Thierry wrote: >> Hi Amit, >> >> On 19/03/2019 08:30, Amit Daniel Kachhap wrote: >>> This adds sections for KVM API extension for pointer authentication. >>> A brief description about usage of pointer authentication for KVM guests >>> is added in the arm64 documentations. > > [...] > >>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >>> index 7de9eee..b5c66bc 100644 >>> --- a/Documentation/virtual/kvm/api.txt >>> +++ b/Documentation/virtual/kvm/api.txt >>> @@ -2659,6 +2659,12 @@ Possible features: >>> Depends on KVM_CAP_ARM_PSCI_0_2. >>> - KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU. >>> Depends on KVM_CAP_ARM_PMU_V3. >>> + - KVM_ARM_VCPU_PTRAUTH_ADDRESS: >>> + - KVM_ARM_VCPU_PTRAUTH_GENERIC: >>> + Enables Pointer authentication for the CPU. >>> + Depends on KVM_CAP_ARM_PTRAUTH and only on arm64 architecture. If >>> + set, then the KVM guest allows the execution of pointer authentication >>> + instructions. Otherwise, KVM treats these instructions as undefined. >>> >> >> Overall I feel one could easily get confused to whether >> PTRAUTH_ADDRESS/GENERIC are two individual features, whether one is a >> superset of the other, if the names are just an alias of one another, etc... >> >> I think the doc should at least stress out that *both* flags are >> required to enable ptrauth in a guest. However it raises the question, >> if we don't plan to support the features individually (because we >> can't), should we really expose two feature flags? I seems odd to >> introduce two flags that only do something if used together... > > Why can't we support the features individually? For example, if we ever > get a system where all CPUs support address authentication and none of > them support generic authentication, then we could still support address > authentication in the guest. > > That's a good point, I didn't think of that. Although, currently we don't have a way to detect that we are in such a configuration. So as is, both flags are required to enable either feature, and I feel the documentation should be clear on that aspect. Another option would be to introduce a flag that enables both for now, and if one day we decide to support the configuration you mentioned we could add "more modular" flags that allow you to control those features individually. While a bit cumbersome, I would find that less awkward than having two flags that only do something if both are present. Thanks, -- Julien Thierry 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=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 1EF01C43381 for ; Wed, 20 Mar 2019 18:07:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 E90452175B for ; Wed, 20 Mar 2019 18:07:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DdZv+/NO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E90452175B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.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:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TTuvN/JEBtC/hPr+gNlfwCspBMotbBqqbHSxEECIQts=; b=DdZv+/NOPeIytz /xU41bBQXC0BWAJHCs1kuadVDF/OmhFSjjE/tXQR1gjH4ZobQ9mlg9I5hNPrslfHLmySjt8XZZa8q j6rytm1KmR1BtC4K2lN0vAAmelmytxnSGYIXRsXKmYcT9ylxAUYsRYtLjkTobtkcx0nvnHNMH4Ot9 AjKRFRxoAvcvJDFlafas9NvHC0dHlZ3d+DY+20RP/a8ZjmACDK1V9ZO9VGLcxJSETY2vVeAsiY5FK rLmKoQi+OerfvFT0WHFZYkSdy21wOP1M8bLnuWSGf4aUE0herT7Ab616NxVN07tkNd20bURqwvCdA cKABISpKIkqOqewM2HJQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h6fcG-0005dx-0o; Wed, 20 Mar 2019 18:07:04 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h6fcB-0005Zd-Mw for linux-arm-kernel@lists.infradead.org; Wed, 20 Mar 2019 18:07:01 +0000 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 09CF8A78; Wed, 20 Mar 2019 11:06:59 -0700 (PDT) Received: from [10.1.197.45] (e112298-lin.cambridge.arm.com [10.1.197.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8CC453F614; Wed, 20 Mar 2019 11:06:55 -0700 (PDT) Subject: Re: [PATCH v7 9/10] KVM: arm64: docs: document KVM support of pointer authentication To: Kristina Martsenko , Amit Daniel Kachhap , linux-arm-kernel@lists.infradead.org References: <1552984243-7689-1-git-send-email-amit.kachhap@arm.com> <1552984243-7689-10-git-send-email-amit.kachhap@arm.com> <7bf19035-02ba-ae47-b08c-7d7622a45dbf@arm.com> <648d66dd-519c-7567-a3e1-c23208f68cf2@arm.com> From: Julien Thierry Message-ID: <52d3f9c8-fc27-bf3d-f8f3-1b3921508a8c@arm.com> Date: Wed, 20 Mar 2019 18:06:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <648d66dd-519c-7567-a3e1-c23208f68cf2@arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190320_110659_896927_D8CD84D8 X-CRM114-Status: GOOD ( 18.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Andrew Jones , Marc Zyngier , Catalin Marinas , Will Deacon , Christoffer Dall , kvmarm@lists.cs.columbia.edu, James Morse , Ramana Radhakrishnan , Dave Martin , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 20/03/2019 15:04, Kristina Martsenko wrote: > On 20/03/2019 13:37, Julien Thierry wrote: >> Hi Amit, >> >> On 19/03/2019 08:30, Amit Daniel Kachhap wrote: >>> This adds sections for KVM API extension for pointer authentication. >>> A brief description about usage of pointer authentication for KVM guests >>> is added in the arm64 documentations. > > [...] > >>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >>> index 7de9eee..b5c66bc 100644 >>> --- a/Documentation/virtual/kvm/api.txt >>> +++ b/Documentation/virtual/kvm/api.txt >>> @@ -2659,6 +2659,12 @@ Possible features: >>> Depends on KVM_CAP_ARM_PSCI_0_2. >>> - KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU. >>> Depends on KVM_CAP_ARM_PMU_V3. >>> + - KVM_ARM_VCPU_PTRAUTH_ADDRESS: >>> + - KVM_ARM_VCPU_PTRAUTH_GENERIC: >>> + Enables Pointer authentication for the CPU. >>> + Depends on KVM_CAP_ARM_PTRAUTH and only on arm64 architecture. If >>> + set, then the KVM guest allows the execution of pointer authentication >>> + instructions. Otherwise, KVM treats these instructions as undefined. >>> >> >> Overall I feel one could easily get confused to whether >> PTRAUTH_ADDRESS/GENERIC are two individual features, whether one is a >> superset of the other, if the names are just an alias of one another, etc... >> >> I think the doc should at least stress out that *both* flags are >> required to enable ptrauth in a guest. However it raises the question, >> if we don't plan to support the features individually (because we >> can't), should we really expose two feature flags? I seems odd to >> introduce two flags that only do something if used together... > > Why can't we support the features individually? For example, if we ever > get a system where all CPUs support address authentication and none of > them support generic authentication, then we could still support address > authentication in the guest. > > That's a good point, I didn't think of that. Although, currently we don't have a way to detect that we are in such a configuration. So as is, both flags are required to enable either feature, and I feel the documentation should be clear on that aspect. Another option would be to introduce a flag that enables both for now, and if one day we decide to support the configuration you mentioned we could add "more modular" flags that allow you to control those features individually. While a bit cumbersome, I would find that less awkward than having two flags that only do something if both are present. Thanks, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel