linux-kernel - Re: [PATCH v5 15/22] KVM: arm64: Support SDEI_EVENT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Mar 2022 23:06:04 +0000
From:   Oliver Upton <oupton@...gle.com>
To:     Gavin Shan <gshan@...hat.com>
Cc:     kvmarm@...ts.cs.columbia.edu, maz@...nel.org,
        linux-kernel@...r.kernel.org, eauger@...hat.com,
        shan.gavin@...il.com, Jonathan.Cameron@...wei.com,
        pbonzini@...hat.com, vkuznets@...hat.com, will@...nel.org
Subject: Re: [PATCH v5 15/22] KVM: arm64: Support SDEI_EVENT_SIGNAL hypercall

Hi Gavin,

On Tue, Mar 22, 2022 at 04:07:03PM +0800, Gavin Shan wrote:
> This supports SDEI_EVENT_SIGNAL hypercall. It's used by the guest
> to inject SDEI event, whose number must be zero to the specified
> vCPU. As the routing mode and affinity isn't supported yet, the
> calling vCPU is assumed to be the target.
> 
> The SDEI event 0x0 is a private one, with normal priority. It's
> usually used for testing.

I don't know if that is actually the case. One real use that immediately
comes to mind is doing an NMI on a wedged CPU. KVM probably shouldn't
glean at how the guest may use a particular call, so at most we should
just point at the spec and state that event 0 is for software signaled
events.

> Signed-off-by: Gavin Shan <gshan@...hat.com>
> ---
>  arch/arm64/kvm/sdei.c | 64 ++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 63 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/sdei.c b/arch/arm64/kvm/sdei.c
> index a24270378305..ba2ca65c871b 100644
> --- a/arch/arm64/kvm/sdei.c
> +++ b/arch/arm64/kvm/sdei.c
> @@ -726,6 +726,66 @@ static int do_inject_event(struct kvm_vcpu *vcpu,
>  	return 0;
>  }
>  
> +static unsigned long hypercall_signal(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm *kvm = vcpu->kvm;
> +	struct kvm_sdei_kvm *ksdei = kvm->arch.sdei;
> +	struct kvm_sdei_vcpu *vsdei = vcpu->arch.sdei;
> +	struct kvm_sdei_exposed_event *exposed_event;
> +	struct kvm_sdei_registered_event *registered_event;
> +	unsigned long event_num = smccc_get_arg1(vcpu);
> +	int index;
> +	unsigned long ret = SDEI_SUCCESS;
> +
> +	/* @event_num must be zero */
> +	if (!kvm_sdei_is_default(event_num)) {

0 isn't KVM's default event. I'd argue KVM doesn't have a default event
to begin with. This has a precise definition coming from the spec. In
fact, 'KVM_SDEI_DEFAULT_EVENT' should probably be eliminated, and any
missing SDEI definitions should be added to include/uapi/linux/arm_sdei.h.

That goes for any values coming from the specification. KVM's
implementation details belong in a KVM header :)

--
Thanks,
Oliver