All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suraj Jitindar Singh <surajjs@amazon.com>
To: <jingzhangos@google.com>
Cc: <alexandru.elisei@arm.com>, <james.morse@arm.com>,
	<kvm@vger.kernel.org>, <kvmarm@lists.linux.dev>,
	<linux-arm-kernel@lists.infradead.org>, <maz@kernel.org>,
	<oupton@google.com>, <pbonzini@redhat.com>, <rananta@google.com>,
	<reijiw@google.com>, <suzuki.poulose@arm.com>, <tabba@google.com>,
	<will@kernel.org>, <sjitindarsingh@gmail.com>,
	"Suraj Jitindar Singh" <surajjs@amazon.com>
Subject: [PATCH 1/3] KVM: arm64: Update id_reg limit value based on per vcpu flags
Date: Fri, 2 Jun 2023 15:14:45 -0700	[thread overview]
Message-ID: <20230602221447.1809849-2-surajjs@amazon.com> (raw)
In-Reply-To: <20230602221447.1809849-1-surajjs@amazon.com>

There are multiple features the availability of which is enabled/disabled
and tracked on a per vcpu level in vcpu->arch.flagset e.g. sve, ptrauth,
and pmu. While the vm wide value of the id regs which represent the
availability of these features is stored in the id_regs kvm struct their
value needs to be manipulated on a per vcpu basis. This is done at read
time in kvm_arm_read_id_reg().

The value of these per vcpu flags needs to be factored in when calculating
the id_reg limit value in check_features() as otherwise we can run into the
following scenario.

[ running on cpu which supports sve ]
1. AA64PFR0.SVE set in id_reg by kvm_arm_init_id_regs() (cpu supports it
   and so is set in value returned from read_sanitised_ftr_reg())
2. vcpus created without sve feature enabled
3. vmm reads AA64PFR0 and attempts to write the same value back
   (writing the same value back is allowed)
4. write fails in check_features() as limit has AA64PFR0.SVE set however it
   is not set in the value being written and although a lower value is
   allowed for this feature it is not in the mask of bits which can be
   modified and so much match exactly.

Thus add a step in check_features() to update the limit returned from
id_reg->reset() with the per vcpu features which may have been
enabled/disabled at vcpu creation time after the id_regs were initialised.
Split this update into a new function named kvm_arm_update_id_reg() so it
can be called from check_features() as well as kvm_arm_read_id_reg() to
dedup code.

Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
---
 arch/arm64/kvm/sys_regs.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 50d4e25f42d3..a4e662bd218b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -42,6 +42,7 @@
  */
 
 static int set_id_reg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, u64 val);
+static u64 kvm_arm_update_id_reg(const struct kvm_vcpu *vcpu, u32 id, u64 val);
 static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding);
 static u64 sys_reg_to_index(const struct sys_reg_desc *reg);
 
@@ -1241,6 +1242,7 @@ static int arm64_check_features(struct kvm_vcpu *vcpu,
 	/* For hidden and unallocated idregs without reset, only val = 0 is allowed. */
 	if (rd->reset) {
 		limit = rd->reset(vcpu, rd);
+		limit = kvm_arm_update_id_reg(vcpu, id, limit);
 		ftr_reg = get_arm64_ftr_reg(id);
 		if (!ftr_reg)
 			return -EINVAL;
@@ -1347,10 +1349,8 @@ static u64 general_read_kvm_sanitised_reg(struct kvm_vcpu *vcpu, const struct sy
 	return read_sanitised_ftr_reg(reg_to_encoding(rd));
 }
 
-static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding)
+static u64 kvm_arm_update_id_reg(const struct kvm_vcpu *vcpu, u32 encoding, u64 val)
 {
-	u64 val = IDREG(vcpu->kvm, encoding);
-
 	switch (encoding) {
 	case SYS_ID_AA64PFR0_EL1:
 		if (!vcpu_has_sve(vcpu))
@@ -1402,6 +1402,13 @@ static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding)
 	return val;
 }
 
+static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding)
+{
+	u64 val = IDREG(vcpu->kvm, encoding);
+
+	return kvm_arm_update_id_reg(vcpu, encoding, val);
+}
+
 /* Read a sanitised cpufeature ID register by sys_reg_desc */
 static u64 read_id_reg(const struct kvm_vcpu *vcpu, struct sys_reg_desc const *r)
 {
-- 
2.34.1


WARNING: multiple messages have this Message-ID (diff)
From: Suraj Jitindar Singh <surajjs@amazon.com>
To: <jingzhangos@google.com>
Cc: <alexandru.elisei@arm.com>, <james.morse@arm.com>,
	<kvm@vger.kernel.org>, <kvmarm@lists.linux.dev>,
	<linux-arm-kernel@lists.infradead.org>, <maz@kernel.org>,
	<oupton@google.com>, <pbonzini@redhat.com>, <rananta@google.com>,
	<reijiw@google.com>, <suzuki.poulose@arm.com>, <tabba@google.com>,
	<will@kernel.org>, <sjitindarsingh@gmail.com>,
	"Suraj Jitindar Singh" <surajjs@amazon.com>
Subject: [PATCH 1/3] KVM: arm64: Update id_reg limit value based on per vcpu flags
Date: Fri, 2 Jun 2023 15:14:45 -0700	[thread overview]
Message-ID: <20230602221447.1809849-2-surajjs@amazon.com> (raw)
In-Reply-To: <20230602221447.1809849-1-surajjs@amazon.com>

There are multiple features the availability of which is enabled/disabled
and tracked on a per vcpu level in vcpu->arch.flagset e.g. sve, ptrauth,
and pmu. While the vm wide value of the id regs which represent the
availability of these features is stored in the id_regs kvm struct their
value needs to be manipulated on a per vcpu basis. This is done at read
time in kvm_arm_read_id_reg().

The value of these per vcpu flags needs to be factored in when calculating
the id_reg limit value in check_features() as otherwise we can run into the
following scenario.

[ running on cpu which supports sve ]
1. AA64PFR0.SVE set in id_reg by kvm_arm_init_id_regs() (cpu supports it
   and so is set in value returned from read_sanitised_ftr_reg())
2. vcpus created without sve feature enabled
3. vmm reads AA64PFR0 and attempts to write the same value back
   (writing the same value back is allowed)
4. write fails in check_features() as limit has AA64PFR0.SVE set however it
   is not set in the value being written and although a lower value is
   allowed for this feature it is not in the mask of bits which can be
   modified and so much match exactly.

Thus add a step in check_features() to update the limit returned from
id_reg->reset() with the per vcpu features which may have been
enabled/disabled at vcpu creation time after the id_regs were initialised.
Split this update into a new function named kvm_arm_update_id_reg() so it
can be called from check_features() as well as kvm_arm_read_id_reg() to
dedup code.

Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
---
 arch/arm64/kvm/sys_regs.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 50d4e25f42d3..a4e662bd218b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -42,6 +42,7 @@
  */
 
 static int set_id_reg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, u64 val);
+static u64 kvm_arm_update_id_reg(const struct kvm_vcpu *vcpu, u32 id, u64 val);
 static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding);
 static u64 sys_reg_to_index(const struct sys_reg_desc *reg);
 
@@ -1241,6 +1242,7 @@ static int arm64_check_features(struct kvm_vcpu *vcpu,
 	/* For hidden and unallocated idregs without reset, only val = 0 is allowed. */
 	if (rd->reset) {
 		limit = rd->reset(vcpu, rd);
+		limit = kvm_arm_update_id_reg(vcpu, id, limit);
 		ftr_reg = get_arm64_ftr_reg(id);
 		if (!ftr_reg)
 			return -EINVAL;
@@ -1347,10 +1349,8 @@ static u64 general_read_kvm_sanitised_reg(struct kvm_vcpu *vcpu, const struct sy
 	return read_sanitised_ftr_reg(reg_to_encoding(rd));
 }
 
-static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding)
+static u64 kvm_arm_update_id_reg(const struct kvm_vcpu *vcpu, u32 encoding, u64 val)
 {
-	u64 val = IDREG(vcpu->kvm, encoding);
-
 	switch (encoding) {
 	case SYS_ID_AA64PFR0_EL1:
 		if (!vcpu_has_sve(vcpu))
@@ -1402,6 +1402,13 @@ static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding)
 	return val;
 }
 
+static u64 kvm_arm_read_id_reg(const struct kvm_vcpu *vcpu, u32 encoding)
+{
+	u64 val = IDREG(vcpu->kvm, encoding);
+
+	return kvm_arm_update_id_reg(vcpu, encoding, val);
+}
+
 /* Read a sanitised cpufeature ID register by sys_reg_desc */
 static u64 read_id_reg(const struct kvm_vcpu *vcpu, struct sys_reg_desc const *r)
 {
-- 
2.34.1


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

  reply	other threads:[~2023-06-02 22:15 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-02  0:51 [PATCH v11 0/5] Support writable CPU ID registers from userspace Jing Zhang
2023-06-02  0:51 ` Jing Zhang
2023-06-02  0:51 ` [PATCH v11 1/5] KVM: arm64: Save ID registers' sanitized value per guest Jing Zhang
2023-06-02  0:51   ` Jing Zhang
2023-06-02  0:51 ` [PATCH v11 2/5] KVM: arm64: Use per guest ID register for ID_AA64PFR0_EL1.[CSV2|CSV3] Jing Zhang
2023-06-02  0:51   ` Jing Zhang
2023-06-02  0:51 ` [PATCH v11 3/5] KVM: arm64: Use per guest ID register for ID_AA64DFR0_EL1.PMUVer Jing Zhang
2023-06-02  0:51   ` Jing Zhang
2023-06-02  0:51 ` [PATCH v11 4/5] KVM: arm64: Reuse fields of sys_reg_desc for idreg Jing Zhang
2023-06-02  0:51   ` Jing Zhang
2023-06-02  0:51 ` [PATCH v11 5/5] KVM: arm64: Refactor writings for PMUVer/CSV2/CSV3 Jing Zhang
2023-06-02  0:51   ` Jing Zhang
2023-06-02 17:15   ` Jing Zhang
2023-06-02 17:15     ` Jing Zhang
2023-06-02 22:27     ` Jitindar Singh, Suraj
2023-06-02 22:27       ` Jitindar Singh, Suraj
2023-06-03  0:08       ` Jing Zhang
2023-06-03  0:08         ` Jing Zhang
2023-06-02 19:21   ` Jitindar Singh, Suraj
2023-06-02 19:21     ` Jitindar Singh, Suraj
2023-06-03  0:03     ` Jing Zhang
2023-06-03  0:03       ` Jing Zhang
2023-06-02 22:14 ` [PATCH 0/3] RE: Support writable CPU ID registers from userspace [v11] Suraj Jitindar Singh
2023-06-02 22:14   ` Suraj Jitindar Singh
2023-06-02 22:14   ` Suraj Jitindar Singh [this message]
2023-06-02 22:14     ` [PATCH 1/3] KVM: arm64: Update id_reg limit value based on per vcpu flags Suraj Jitindar Singh
2023-06-02 22:14   ` [PATCH 2/3] KVM: arm64: Move non per vcpu flag checks out of kvm_arm_update_id_reg() Suraj Jitindar Singh
2023-06-02 22:14     ` Suraj Jitindar Singh
2023-06-02 22:14   ` [PATCH 3/3] KVM: arm64: Use per guest ID register for ID_AA64PFR1_EL1.MTE Suraj Jitindar Singh
2023-06-02 22:14     ` Suraj Jitindar Singh
2023-06-03  8:28     ` Marc Zyngier
2023-06-03  8:28       ` Marc Zyngier
2023-06-05 16:39       ` Cornelia Huck
2023-06-05 16:39         ` Cornelia Huck
2023-06-06 16:42         ` Marc Zyngier
2023-06-06 16:42           ` Marc Zyngier
2023-06-07 10:09           ` Cornelia Huck
2023-06-07 10:09             ` Cornelia Huck
2023-06-08 17:57           ` Catalin Marinas
2023-06-08 17:57             ` Catalin Marinas

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=20230602221447.1809849-2-surajjs@amazon.com \
    --to=surajjs@amazon.com \
    --cc=alexandru.elisei@arm.com \
    --cc=james.morse@arm.com \
    --cc=jingzhangos@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=rananta@google.com \
    --cc=reijiw@google.com \
    --cc=sjitindarsingh@gmail.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    /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.