kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: kvmarm@lists.cs.columbia.edu, Paolo Bonzini <pbonzini@redhat.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Anup Patel <anup@brainfault.org>,
	Atish Patra <atishp@atishpatra.org>,
	Sean Christopherson <seanjc@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
	Peter Shier <pshier@google.com>,
	Reiji Watanabe <reijiw@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Raghavendra Rao Ananta <rananta@google.com>,
	Jing Zhang <jingzhangos@google.com>
Subject: Re: [PATCH v3 03/19] KVM: arm64: Reject invalid addresses for CPU_ON PSCI call
Date: Fri, 25 Feb 2022 15:35:12 +0000	[thread overview]
Message-ID: <87ilt32c3z.wl-maz@kernel.org> (raw)
In-Reply-To: <YhfaztgV0GHzyh24@google.com>

On Thu, 24 Feb 2022 19:21:50 +0000,
Oliver Upton <oupton@google.com> wrote:
> 
> Hi Marc,
> 
> On Thu, Feb 24, 2022 at 12:30:49PM +0000, Marc Zyngier wrote:
> > On Wed, 23 Feb 2022 04:18:28 +0000,
> > Oliver Upton <oupton@google.com> wrote:
> > > 
> > > DEN0022D.b 5.6.2 "Caller responsibilities" states that a PSCI
> > > implementation may return INVALID_ADDRESS for the CPU_ON call if the
> > > provided entry address is known to be invalid. There is an additional
> > > caveat to this rule. Prior to PSCI v1.0, the INVALID_PARAMETERS error
> > > is returned instead. Check the guest's PSCI version and return the
> > > appropriate error if the IPA is invalid.
> > > 
> > > Reported-by: Reiji Watanabe <reijiw@google.com>
> > > Signed-off-by: Oliver Upton <oupton@google.com>
> > > ---
> > >  arch/arm64/kvm/psci.c | 24 ++++++++++++++++++++++--
> > >  1 file changed, 22 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> > > index a0c10c11f40e..de1cf554929d 100644
> > > --- a/arch/arm64/kvm/psci.c
> > > +++ b/arch/arm64/kvm/psci.c
> > > @@ -12,6 +12,7 @@
> > >  
> > >  #include <asm/cputype.h>
> > >  #include <asm/kvm_emulate.h>
> > > +#include <asm/kvm_mmu.h>
> > >  
> > >  #include <kvm/arm_psci.h>
> > >  #include <kvm/arm_hypercalls.h>
> > > @@ -70,12 +71,31 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> > >  	struct vcpu_reset_state *reset_state;
> > >  	struct kvm *kvm = source_vcpu->kvm;
> > >  	struct kvm_vcpu *vcpu = NULL;
> > > -	unsigned long cpu_id;
> > > +	unsigned long cpu_id, entry_addr;
> > >  
> > >  	cpu_id = smccc_get_arg1(source_vcpu);
> > >  	if (!kvm_psci_valid_affinity(source_vcpu, cpu_id))
> > >  		return PSCI_RET_INVALID_PARAMS;
> > >  
> > > +	/*
> > > +	 * Basic sanity check: ensure the requested entry address actually
> > > +	 * exists within the guest's address space.
> > > +	 */
> > > +	entry_addr = smccc_get_arg2(source_vcpu);
> > > +	if (!kvm_ipa_valid(kvm, entry_addr)) {
> > > +
> > > +		/*
> > > +		 * Before PSCI v1.0, the INVALID_PARAMETERS error is returned
> > > +		 * instead of INVALID_ADDRESS.
> > > +		 *
> > > +		 * For more details, see ARM DEN0022D.b 5.6 "CPU_ON".
> > > +		 */
> > > +		if (kvm_psci_version(source_vcpu) < KVM_ARM_PSCI_1_0)
> > > +			return PSCI_RET_INVALID_PARAMS;
> > > +		else
> > > +			return PSCI_RET_INVALID_ADDRESS;
> > > +	}
> > > +
> > 
> > If you're concerned with this, should you also check for the PC
> > alignment, or the presence of a memslot covering the address you are
> > branching to?  Le latter is particularly hard to implement reliably.
> 
> Andrew, Reiji and I had a conversation regarding exactly this on the
> last run of this series, and concluded that checking against the IPA is
> probably the best KVM can do [1]. That said, alignment is also an easy
> thing to check.

Until you look at Thumb-2 ;-)

> 
> > So far, my position has been that the guest is free to shoot itself in
> > the foot if that's what it wants to do, and that babysitting it was a
> > waste of useful bits! ;-)
> >
> 
> Agreed -- there are plenty of spectacular/hilarious ways in which the
> guest can mess up :-)
> 
> > Or have you identified something that makes it a requirement to handle
> > this case (and possibly others)  in the hypervisor?
> 
> It is a lot easier to tell a guest that their software is broken if they
> get an error back from the hypercall, whereas a vCPU off in the weeds
> might need to be looked at before concluding there's a guest issue.

Fair enough. I'm not fundamentally against this patch. It is just a
bit out of context in this series.

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-02-25 15:35 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23  4:18 [PATCH v3 00/19] KVM: arm64: Implement PSCI SYSTEM_SUSPEND Oliver Upton
2022-02-23  4:18 ` [PATCH v3 01/19] KVM: arm64: Drop unused param from kvm_psci_version() Oliver Upton
2022-02-24  6:14   ` Reiji Watanabe
2022-02-23  4:18 ` [PATCH v3 02/19] KVM: arm64: Create a helper to check if IPA is valid Oliver Upton
2022-02-24  6:32   ` Reiji Watanabe
2022-02-24 12:06   ` Marc Zyngier
2022-02-23  4:18 ` [PATCH v3 03/19] KVM: arm64: Reject invalid addresses for CPU_ON PSCI call Oliver Upton
2022-02-24  6:55   ` Reiji Watanabe
2022-02-24 12:30   ` Marc Zyngier
2022-02-24 19:21     ` Oliver Upton
2022-02-25 15:35       ` Marc Zyngier [this message]
2022-02-23  4:18 ` [PATCH v3 04/19] KVM: arm64: Clean up SMC64 PSCI filtering for AArch32 guests Oliver Upton
2022-02-23  4:18 ` [PATCH v3 05/19] KVM: arm64: Dedupe vCPU power off helpers Oliver Upton
2022-02-24  7:07   ` Reiji Watanabe
2022-02-23  4:18 ` [PATCH v3 06/19] KVM: arm64: Track vCPU power state using MP state values Oliver Upton
2022-02-24 13:25   ` Marc Zyngier
2022-02-24 22:08     ` Oliver Upton
2022-02-25 15:37       ` Marc Zyngier
2022-02-23  4:18 ` [PATCH v3 07/19] KVM: arm64: Rename the KVM_REQ_SLEEP handler Oliver Upton
2022-02-23  4:18 ` [PATCH v3 08/19] KVM: arm64: Add reset helper that accepts caller-provided reset state Oliver Upton
2022-02-23  4:18 ` [PATCH v3 09/19] KVM: arm64: Implement PSCI SYSTEM_SUSPEND Oliver Upton
2022-02-24 14:02   ` Marc Zyngier
2022-02-24 19:35     ` Oliver Upton
2022-02-25 18:58       ` Marc Zyngier
2022-03-03  1:01         ` Oliver Upton
2022-03-03 11:37           ` Marc Zyngier
2022-02-23  4:18 ` [PATCH v3 10/19] KVM: Create helper for setting a system event exit Oliver Upton
2022-02-23  6:37   ` Anup Patel
2022-02-24 14:07   ` Marc Zyngier
2022-02-23  4:18 ` [PATCH v3 11/19] KVM: arm64: Return a value from check_vcpu_requests() Oliver Upton
2022-02-23  4:18 ` [PATCH v3 12/19] KVM: arm64: Add support for userspace to suspend a vCPU Oliver Upton
2022-02-24 15:12   ` Marc Zyngier
2022-02-24 19:47     ` Oliver Upton
2022-02-23  4:18 ` [PATCH v3 13/19] KVM: arm64: Add support KVM_SYSTEM_EVENT_SUSPEND to PSCI SYSTEM_SUSPEND Oliver Upton
2022-02-24 15:40   ` Marc Zyngier
2022-02-24 20:05     ` Oliver Upton
2022-02-26 11:29       ` Marc Zyngier
2022-02-26 18:28         ` Oliver Upton
2022-03-02  9:52           ` Marc Zyngier
2022-03-02  9:57             ` Oliver Upton
2022-02-23  4:18 ` [PATCH v3 14/19] KVM: arm64: Raise default PSCI version to v1.1 Oliver Upton
2022-02-23  4:26   ` Oliver Upton
2022-02-23  4:18 ` [PATCH v3 15/19] selftests: KVM: Rename psci_cpu_on_test to psci_test Oliver Upton
2022-02-23  4:18 ` [PATCH v3 16/19] selftests: KVM: Create helper for making SMCCC calls Oliver Upton
2022-02-23  4:18 ` [PATCH v3 17/19] selftests: KVM: Use KVM_SET_MP_STATE to power off vCPU in psci_test Oliver Upton
2022-02-23  4:18 ` [PATCH v3 18/19] selftests: KVM: Refactor psci_test to make it amenable to new tests Oliver Upton
2022-02-23  4:18 ` [PATCH v3 19/19] selftests: KVM: Test SYSTEM_SUSPEND PSCI call Oliver Upton

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=87ilt32c3z.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=anup@brainfault.org \
    --cc=atishp@atishpatra.org \
    --cc=james.morse@arm.com \
    --cc=jingzhangos@google.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm-riscv@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pshier@google.com \
    --cc=rananta@google.com \
    --cc=reijiw@google.com \
    --cc=ricarkol@google.com \
    --cc=seanjc@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).