From: Marc Zyngier <maz@kernel.org>
To: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
Joey Gouly <joey.gouly@arm.com>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: [PATCH v3 10/15] KVM: arm64: nv: Reinject PAC exceptions caused by HCR_EL2.API==0
Date: Thu, 21 Mar 2024 15:53:51 +0000 [thread overview]
Message-ID: <20240321155356.3236459-11-maz@kernel.org> (raw)
In-Reply-To: <20240321155356.3236459-1-maz@kernel.org>
In order for a L1 hypervisor to correctly handle PAuth instructions,
it must observe traps caused by a L1 PAuth instruction when
HCR_EL2.API==0. Since we already handle the case for API==1 as
a fixup, only the exception injection case needs to be handled.
Rework the kvm_handle_ptrauth() callback to reinject the trap
in this case. Note that APK==0 is already handled by the exising
triage_sysreg_trap() helper.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/handle_exit.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 6a88ec024e2f..1ba2f788b2c3 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -214,12 +214,34 @@ static int handle_sve(struct kvm_vcpu *vcpu)
}
/*
- * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into
- * a NOP). If we get here, it is that we didn't fixup ptrauth on exit, and all
- * that we can do is give the guest an UNDEF.
+ * Two possibilities to handle a trapping ptrauth instruction:
+ *
+ * - Guest usage of a ptrauth instruction (which the guest EL1 did not
+ * turn into a NOP). If we get here, it is that we didn't fixup
+ * ptrauth on exit, and all that we can do is give the guest an
+ * UNDEF (as the guest isn't supposed to use ptrauth without being
+ * told it could).
+ *
+ * - Running an L2 NV guest while L1 has left HCR_EL2.API==0, and for
+ * which we reinject the exception into L1. API==1 is handled as a
+ * fixup so the only way to get here is when API==0.
+ *
+ * Anything else is an emulation bug (hence the WARN_ON + UNDEF).
*/
static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu)
{
+ if (!vcpu_has_ptrauth(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return 1;
+ }
+
+ if (vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu)) {
+ kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
+ return 1;
+ }
+
+ /* Really shouldn't be here! */
+ WARN_ON_ONCE(1);
kvm_inject_undefined(vcpu);
return 1;
}
--
2.39.2
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
Joey Gouly <joey.gouly@arm.com>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: [PATCH v3 10/15] KVM: arm64: nv: Reinject PAC exceptions caused by HCR_EL2.API==0
Date: Thu, 21 Mar 2024 15:53:51 +0000 [thread overview]
Message-ID: <20240321155356.3236459-11-maz@kernel.org> (raw)
In-Reply-To: <20240321155356.3236459-1-maz@kernel.org>
In order for a L1 hypervisor to correctly handle PAuth instructions,
it must observe traps caused by a L1 PAuth instruction when
HCR_EL2.API==0. Since we already handle the case for API==1 as
a fixup, only the exception injection case needs to be handled.
Rework the kvm_handle_ptrauth() callback to reinject the trap
in this case. Note that APK==0 is already handled by the exising
triage_sysreg_trap() helper.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/handle_exit.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 6a88ec024e2f..1ba2f788b2c3 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -214,12 +214,34 @@ static int handle_sve(struct kvm_vcpu *vcpu)
}
/*
- * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into
- * a NOP). If we get here, it is that we didn't fixup ptrauth on exit, and all
- * that we can do is give the guest an UNDEF.
+ * Two possibilities to handle a trapping ptrauth instruction:
+ *
+ * - Guest usage of a ptrauth instruction (which the guest EL1 did not
+ * turn into a NOP). If we get here, it is that we didn't fixup
+ * ptrauth on exit, and all that we can do is give the guest an
+ * UNDEF (as the guest isn't supposed to use ptrauth without being
+ * told it could).
+ *
+ * - Running an L2 NV guest while L1 has left HCR_EL2.API==0, and for
+ * which we reinject the exception into L1. API==1 is handled as a
+ * fixup so the only way to get here is when API==0.
+ *
+ * Anything else is an emulation bug (hence the WARN_ON + UNDEF).
*/
static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu)
{
+ if (!vcpu_has_ptrauth(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return 1;
+ }
+
+ if (vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu)) {
+ kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
+ return 1;
+ }
+
+ /* Really shouldn't be here! */
+ WARN_ON_ONCE(1);
kvm_inject_undefined(vcpu);
return 1;
}
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-21 15:54 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 15:53 [PATCH v3 00/15] KVM/arm64: Add NV support for ERET and PAuth Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 01/15] KVM: arm64: Harden __ctxt_sys_reg() against out-of-range values Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 02/15] KVM: arm64: Add helpers for ESR_ELx_ERET_ISS_ERET* Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 03/15] KVM: arm64: Constraint PAuth support to consistent implementations Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 04/15] KVM: arm64: nv: Drop VCPU_HYP_CONTEXT flag Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-04-16 20:06 ` Oliver Upton
2024-04-16 20:06 ` Oliver Upton
2024-04-17 7:51 ` Marc Zyngier
2024-04-17 7:51 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 05/15] KVM: arm64: nv: Configure HCR_EL2 for FEAT_NV2 Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 06/15] KVM: arm64: nv: Add trap forwarding for ERET and SMC Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 07/15] KVM: arm64: nv: Fast-track 'InHost' exception returns Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 08/15] KVM: arm64: nv: Honor HFGITR_EL2.ERET being set Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 09/15] KVM: arm64: nv: Handle HCR_EL2.{API,APK} independently Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier [this message]
2024-03-21 15:53 ` [PATCH v3 10/15] KVM: arm64: nv: Reinject PAC exceptions caused by HCR_EL2.API==0 Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 11/15] KVM: arm64: nv: Add kvm_has_pauth() helper Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 12/15] KVM: arm64: nv: Add emulation for ERETAx instructions Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 13/15] KVM: arm64: nv: Handle ERETA[AB] instructions Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 14/15] KVM: arm64: nv: Advertise support for PAuth Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
2024-03-21 15:53 ` [PATCH v3 15/15] KVM: arm64: Drop trapping of PAuth instructions/keys Marc Zyngier
2024-03-21 15:53 ` Marc Zyngier
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=20240321155356.3236459-11-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.