All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amit Daniel Kachhap <amit.kachhap@arm.com>
To: Kristina Martsenko <kristina.martsenko@arm.com>,
	Julien Thierry <julien.thierry@arm.com>,
	linux-arm-kernel@lists.infradead.org
Cc: Christoffer Dall <christoffer.dall@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrew Jones <drjones@redhat.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	Mark Rutland <mark.rutland@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH v7 9/10] KVM: arm64: docs: document KVM support of pointer authentication
Date: Thu, 21 Mar 2019 12:11:01 +0530	[thread overview]
Message-ID: <462c5f79-b0d6-8c4b-ce43-2dfcc0f3b7a6@arm.com> (raw)
In-Reply-To: <6d84723d-e00e-e89f-4c42-d48d0eb03443@arm.com>

Hi Julien/Kristina,

On 3/21/19 2:26 AM, Kristina Martsenko wrote:
> On 20/03/2019 18:06, Julien Thierry wrote:
>>
>>
>> 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.
> 
> For now we only support enabling both features together, so both flags
> need to be set. I agree that the documentation should be made clear on this.
> 
> In the future, if we need to, we can add "negative" cpucaps to detect
> that a feature is absent on all CPUs.
> 
>>
>> 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.
> 
> That would work too.
> 
> I find it more logical to have two flags since there are two features
> (two ID register fields), and KVM enables two features for the guest.
> The fact that KVM does not currently support enabling them separately is
> a KVM implementation choice, and could change in the future.
Kristina, this comments of yours is actually what this patch series is 
trying to do. I should have added more details about the necessity of 
keeping two flags and enhancement of them is actually a future work.

Thanks,
Amit Daniel
> 
> Thanks,
> Kristina
> 

WARNING: multiple messages have this Message-ID (diff)
From: Amit Daniel Kachhap <amit.kachhap@arm.com>
To: Kristina Martsenko <kristina.martsenko@arm.com>,
	Julien Thierry <julien.thierry@arm.com>,
	linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	Andrew Jones <drjones@redhat.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	kvmarm@lists.cs.columbia.edu, James Morse <james.morse@arm.com>,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 9/10] KVM: arm64: docs: document KVM support of pointer authentication
Date: Thu, 21 Mar 2019 12:11:01 +0530	[thread overview]
Message-ID: <462c5f79-b0d6-8c4b-ce43-2dfcc0f3b7a6@arm.com> (raw)
In-Reply-To: <6d84723d-e00e-e89f-4c42-d48d0eb03443@arm.com>

Hi Julien/Kristina,

On 3/21/19 2:26 AM, Kristina Martsenko wrote:
> On 20/03/2019 18:06, Julien Thierry wrote:
>>
>>
>> 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.
> 
> For now we only support enabling both features together, so both flags
> need to be set. I agree that the documentation should be made clear on this.
> 
> In the future, if we need to, we can add "negative" cpucaps to detect
> that a feature is absent on all CPUs.
> 
>>
>> 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.
> 
> That would work too.
> 
> I find it more logical to have two flags since there are two features
> (two ID register fields), and KVM enables two features for the guest.
> The fact that KVM does not currently support enabling them separately is
> a KVM implementation choice, and could change in the future.
Kristina, this comments of yours is actually what this patch series is 
trying to do. I should have added more details about the necessity of 
keeping two flags and enhancement of them is actually a future work.

Thanks,
Amit Daniel
> 
> Thanks,
> Kristina
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-21  6:41 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19  8:30 [PATCH v7 0/10] Add ARMv8.3 pointer authentication for kvm guest Amit Daniel Kachhap
2019-03-19  8:30 ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 1/10] KVM: arm64: Propagate vcpu into read_id_reg() Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 2/10] KVM: arm64: Support runtime sysreg visibility filtering Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 3/10] KVM: arm64: Move hyp_symbol_addr to fix dependency Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-20  8:49   ` Julien Thierry
2019-03-20  8:49     ` Julien Thierry
2019-03-21  5:29     ` Amit Daniel Kachhap
2019-03-21  5:29       ` Amit Daniel Kachhap
2019-03-21  5:29       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 4/10] KVM: arm/arm64: preserve host HCR_EL2 value Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 5/10] KVM: arm/arm64: preserve host MDCR_EL2 value Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-25 20:04   ` Kristina Martsenko
2019-03-25 20:04     ` Kristina Martsenko
2019-03-26  3:55     ` Amit Daniel Kachhap
2019-03-26  3:55       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 6/10] KVM: arm64: Add vcpu feature flags to control ptrauth accessibility Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 7/10] KVM: arm/arm64: context-switch ptrauth registers Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-20 12:13   ` Julien Thierry
2019-03-20 12:13     ` Julien Thierry
2019-03-21  6:08     ` Amit Daniel Kachhap
2019-03-21  6:08       ` Amit Daniel Kachhap
2019-03-21  8:29       ` Julien Thierry
2019-03-21  8:29         ` Julien Thierry
2019-03-25 20:04   ` Kristina Martsenko
2019-03-25 20:04     ` Kristina Martsenko
2019-03-26  4:03     ` Amit Daniel Kachhap
2019-03-26  4:03       ` Amit Daniel Kachhap
2019-03-26 18:01       ` Kristina Martsenko
2019-03-26 18:01         ` Kristina Martsenko
2019-03-27  3:21         ` Amit Daniel Kachhap
2019-03-27  3:21           ` Amit Daniel Kachhap
2019-03-27  3:21           ` Amit Daniel Kachhap
2019-03-27 18:16           ` James Morse
2019-03-27 18:16             ` James Morse
2019-03-27 18:16             ` James Morse
2019-03-28 11:29             ` Amit Daniel Kachhap
2019-03-28 11:29               ` Amit Daniel Kachhap
2019-03-28 18:51   ` James Morse
2019-03-28 18:51     ` James Morse
2019-03-29  5:54     ` Amit Daniel Kachhap
2019-03-29  5:54       ` Amit Daniel Kachhap
2019-03-29  5:54       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 8/10] KVM: arm64: Add capability to advertise ptrauth for guest Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-25 20:05   ` Kristina Martsenko
2019-03-25 20:05     ` Kristina Martsenko
2019-03-26  4:12     ` Amit Daniel Kachhap
2019-03-26  4:12       ` Amit Daniel Kachhap
2019-03-26  4:12       ` Amit Daniel Kachhap
2019-03-19  8:30 ` [PATCH v7 9/10] KVM: arm64: docs: document KVM support of pointer authentication Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap
2019-03-20 13:37   ` Julien Thierry
2019-03-20 13:37     ` Julien Thierry
2019-03-20 15:04     ` Kristina Martsenko
2019-03-20 15:04       ` Kristina Martsenko
2019-03-20 18:06       ` Julien Thierry
2019-03-20 18:06         ` Julien Thierry
2019-03-20 20:56         ` Kristina Martsenko
2019-03-20 20:56           ` Kristina Martsenko
2019-03-21  6:41           ` Amit Daniel Kachhap [this message]
2019-03-21  6:41             ` Amit Daniel Kachhap
2019-03-25 20:05   ` Kristina Martsenko
2019-03-25 20:05     ` Kristina Martsenko
2019-03-27 10:44     ` Dave Martin
2019-03-27 10:44       ` Dave Martin
2019-03-27 11:49       ` Amit Daniel Kachhap
2019-03-27 11:49         ` Amit Daniel Kachhap
2019-03-27 13:50         ` Dave Martin
2019-03-27 13:50           ` Dave Martin
2019-03-28 10:13           ` Amit Daniel Kachhap
2019-03-28 10:13             ` Amit Daniel Kachhap
2019-03-19  8:30 ` [kvmtool PATCH v7 10/10] KVM: arm/arm64: Add a vcpu feature for " Amit Daniel Kachhap
2019-03-19  8:30   ` Amit Daniel Kachhap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=462c5f79-b0d6-8c4b-ce43-2dfcc0f3b7a6@arm.com \
    --to=amit.kachhap@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=drjones@redhat.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=ramana.radhakrishnan@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.