All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kernel-team@android.com,
	stable@vger.kernel.org, Steven Price <steven.price@arm.com>
Subject: Re: [PATCH] KVM: arm64: Prevent mixed-width VM creation
Date: Thu, 20 May 2021 13:58:55 +0100	[thread overview]
Message-ID: <87zgwptvcg.wl-maz@kernel.org> (raw)
In-Reply-To: <20210520124434.GD17233@C02TD0UTHF1T.local>

On Thu, 20 May 2021 13:44:34 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Thu, May 20, 2021 at 01:22:53PM +0100, Marc Zyngier wrote:
> > It looks like we have tolerated creating mixed-width VMs since...
> > forever. However, that was never the intention, and we'd rather
> > not have to support that pointless complexity.
> > 
> > Forbid such a setup by making sure all the vcpus have the same
> > register width.
> > 
> > Reported-by: Steven Price <steven.price@arm.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Cc: stable@vger.kernel.org
> > ---
> >  arch/arm64/kvm/reset.c | 28 ++++++++++++++++++++++++----
> >  1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index 956cdc240148..1cf308be6ef3 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -166,6 +166,25 @@ static int kvm_vcpu_enable_ptrauth(struct kvm_vcpu *vcpu)
> >  	return 0;
> >  }
> >  
> > +static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
> > +{
> > +	struct kvm_vcpu *tmp;
> > +	int i;
> > +
> > +	/* Check that the vcpus are either all 32bit or all 64bit */
> > +	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> > +		bool w;
> > +
> > +		w  = test_bit(KVM_ARM_VCPU_EL1_32BIT, tmp->arch.features);
> > +		w ^= test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features);
> > +
> > +		if (w)
> > +			return false;
> > +	}
> 
> I think this is wrong for a single-cpu VM. In that case, the loop will
> have a single iteration, and tmp == vcpu, so w must be 0 regardless of
> the value of arch.features.

I don't immediately see what is wrong with a single-cpu VM. 'w' will
be zero indeed, and we'll return that this is allowed. After all, each
VM starts by being a single-CPU VM.

But of course...

> IIUC that doesn't prevent KVM_ARM_VCPU_EL1_32BIT being set when we don't
> have the ARM64_HAS_32BIT_EL1 cap, unless that's checked elsewhere?

... I mistakenly removed the check against ARM64_HAS_32BIT_EL1...

> 
> How about something like:
> 
> | static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
> | {
> | 	bool is_32bit = vcpu_features_32bit(vcpu);
> | 	struct kvm_vcpu *tmp;
> | 	int i;
> | 
> | 	if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is_32bit)
> | 		return false;
> | 
> | 	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> | 		if (is_32bit != vcpu_features_32bit(tmp))
> | 			return false;
> | 	}
> | 
> | 	return true;
> | }
> 
> ... with a helper in <asm/kvm_emulate.h> like:
> 
> | static bool vcpu_features_32bit(struct kvm_vcpu *vcpu)
> | {
> | 	return test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features);
> | }
> 
> ... or
> 
> | static inline bool vcpu_has_feature(struct kvm_vcpu *vcpu, int feature)
> | {
> | 	return test_bit(feature, vcpu->arch.features);
> | }
> 
> ... so that we can avoid the line splitting required by the length of
> the test_bit() expression?

Yup, looks OK to me (with a preference for the latter).

Thanks,

	M.

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

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: stable@vger.kernel.org, kernel-team@android.com,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Steven Price <steven.price@arm.com>
Subject: Re: [PATCH] KVM: arm64: Prevent mixed-width VM creation
Date: Thu, 20 May 2021 13:58:55 +0100	[thread overview]
Message-ID: <87zgwptvcg.wl-maz@kernel.org> (raw)
In-Reply-To: <20210520124434.GD17233@C02TD0UTHF1T.local>

On Thu, 20 May 2021 13:44:34 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Thu, May 20, 2021 at 01:22:53PM +0100, Marc Zyngier wrote:
> > It looks like we have tolerated creating mixed-width VMs since...
> > forever. However, that was never the intention, and we'd rather
> > not have to support that pointless complexity.
> > 
> > Forbid such a setup by making sure all the vcpus have the same
> > register width.
> > 
> > Reported-by: Steven Price <steven.price@arm.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Cc: stable@vger.kernel.org
> > ---
> >  arch/arm64/kvm/reset.c | 28 ++++++++++++++++++++++++----
> >  1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index 956cdc240148..1cf308be6ef3 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -166,6 +166,25 @@ static int kvm_vcpu_enable_ptrauth(struct kvm_vcpu *vcpu)
> >  	return 0;
> >  }
> >  
> > +static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
> > +{
> > +	struct kvm_vcpu *tmp;
> > +	int i;
> > +
> > +	/* Check that the vcpus are either all 32bit or all 64bit */
> > +	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> > +		bool w;
> > +
> > +		w  = test_bit(KVM_ARM_VCPU_EL1_32BIT, tmp->arch.features);
> > +		w ^= test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features);
> > +
> > +		if (w)
> > +			return false;
> > +	}
> 
> I think this is wrong for a single-cpu VM. In that case, the loop will
> have a single iteration, and tmp == vcpu, so w must be 0 regardless of
> the value of arch.features.

I don't immediately see what is wrong with a single-cpu VM. 'w' will
be zero indeed, and we'll return that this is allowed. After all, each
VM starts by being a single-CPU VM.

But of course...

> IIUC that doesn't prevent KVM_ARM_VCPU_EL1_32BIT being set when we don't
> have the ARM64_HAS_32BIT_EL1 cap, unless that's checked elsewhere?

... I mistakenly removed the check against ARM64_HAS_32BIT_EL1...

> 
> How about something like:
> 
> | static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
> | {
> | 	bool is_32bit = vcpu_features_32bit(vcpu);
> | 	struct kvm_vcpu *tmp;
> | 	int i;
> | 
> | 	if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is_32bit)
> | 		return false;
> | 
> | 	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> | 		if (is_32bit != vcpu_features_32bit(tmp))
> | 			return false;
> | 	}
> | 
> | 	return true;
> | }
> 
> ... with a helper in <asm/kvm_emulate.h> like:
> 
> | static bool vcpu_features_32bit(struct kvm_vcpu *vcpu)
> | {
> | 	return test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features);
> | }
> 
> ... or
> 
> | static inline bool vcpu_has_feature(struct kvm_vcpu *vcpu, int feature)
> | {
> | 	return test_bit(feature, vcpu->arch.features);
> | }
> 
> ... so that we can avoid the line splitting required by the length of
> the test_bit() expression?

Yup, looks OK to me (with a preference for the latter).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kernel-team@android.com,
	stable@vger.kernel.org, Steven Price <steven.price@arm.com>
Subject: Re: [PATCH] KVM: arm64: Prevent mixed-width VM creation
Date: Thu, 20 May 2021 13:58:55 +0100	[thread overview]
Message-ID: <87zgwptvcg.wl-maz@kernel.org> (raw)
In-Reply-To: <20210520124434.GD17233@C02TD0UTHF1T.local>

On Thu, 20 May 2021 13:44:34 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Thu, May 20, 2021 at 01:22:53PM +0100, Marc Zyngier wrote:
> > It looks like we have tolerated creating mixed-width VMs since...
> > forever. However, that was never the intention, and we'd rather
> > not have to support that pointless complexity.
> > 
> > Forbid such a setup by making sure all the vcpus have the same
> > register width.
> > 
> > Reported-by: Steven Price <steven.price@arm.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Cc: stable@vger.kernel.org
> > ---
> >  arch/arm64/kvm/reset.c | 28 ++++++++++++++++++++++++----
> >  1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index 956cdc240148..1cf308be6ef3 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -166,6 +166,25 @@ static int kvm_vcpu_enable_ptrauth(struct kvm_vcpu *vcpu)
> >  	return 0;
> >  }
> >  
> > +static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
> > +{
> > +	struct kvm_vcpu *tmp;
> > +	int i;
> > +
> > +	/* Check that the vcpus are either all 32bit or all 64bit */
> > +	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> > +		bool w;
> > +
> > +		w  = test_bit(KVM_ARM_VCPU_EL1_32BIT, tmp->arch.features);
> > +		w ^= test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features);
> > +
> > +		if (w)
> > +			return false;
> > +	}
> 
> I think this is wrong for a single-cpu VM. In that case, the loop will
> have a single iteration, and tmp == vcpu, so w must be 0 regardless of
> the value of arch.features.

I don't immediately see what is wrong with a single-cpu VM. 'w' will
be zero indeed, and we'll return that this is allowed. After all, each
VM starts by being a single-CPU VM.

But of course...

> IIUC that doesn't prevent KVM_ARM_VCPU_EL1_32BIT being set when we don't
> have the ARM64_HAS_32BIT_EL1 cap, unless that's checked elsewhere?

... I mistakenly removed the check against ARM64_HAS_32BIT_EL1...

> 
> How about something like:
> 
> | static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
> | {
> | 	bool is_32bit = vcpu_features_32bit(vcpu);
> | 	struct kvm_vcpu *tmp;
> | 	int i;
> | 
> | 	if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is_32bit)
> | 		return false;
> | 
> | 	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> | 		if (is_32bit != vcpu_features_32bit(tmp))
> | 			return false;
> | 	}
> | 
> | 	return true;
> | }
> 
> ... with a helper in <asm/kvm_emulate.h> like:
> 
> | static bool vcpu_features_32bit(struct kvm_vcpu *vcpu)
> | {
> | 	return test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features);
> | }
> 
> ... or
> 
> | static inline bool vcpu_has_feature(struct kvm_vcpu *vcpu, int feature)
> | {
> | 	return test_bit(feature, vcpu->arch.features);
> | }
> 
> ... so that we can avoid the line splitting required by the length of
> the test_bit() expression?

Yup, looks OK to me (with a preference for the latter).

Thanks,

	M.

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

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

  reply	other threads:[~2021-05-20 12:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 12:22 [PATCH] KVM: arm64: Prevent mixed-width VM creation Marc Zyngier
2021-05-20 12:22 ` Marc Zyngier
2021-05-20 12:22 ` Marc Zyngier
2021-05-20 12:44 ` Mark Rutland
2021-05-20 12:44   ` Mark Rutland
2021-05-20 12:44   ` Mark Rutland
2021-05-20 12:58   ` Marc Zyngier [this message]
2021-05-20 12:58     ` Marc Zyngier
2021-05-20 12:58     ` Marc Zyngier
2021-05-20 14:06     ` Mark Rutland
2021-05-20 14:06       ` Mark Rutland
2021-05-20 14:06       ` Mark Rutland

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=87zgwptvcg.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=steven.price@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.