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>] [day] [month] [year] [list]
Message-ID: <e489252745ac4b53f1f7f50570b03fb416aa2065.camel@infradead.org>
Date: Thu, 08 May 2025 13:30:12 -0700
From: David Woodhouse <dwmw2@...radead.org>
To: kvm@...r.kernel.org, Sean Christopherson <seanjc@...gle.com>, "Orlov,
 Ivan" <iorlov@...zon.co.uk>
Cc: Paul Durrant <paul@....org>, Paolo Bonzini <pbonzini@...hat.com>, Thomas
 Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav
 Petkov <bp@...en8.de>,  Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, 
 linux-kernel@...r.kernel.org
Subject: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ
 routing table.

From: David Woodhouse <dwmw@...zon.co.uk>

To avoid imposing an ordering constraint on userspace, allow 'invalid'
event channel targets to be configured in the IRQ routing table.

This is the same as accepting interrupts targeted at vCPUs which don't
exist yet, which is already the case for both Xen event channels *and*
for MSIs (which don't do any filtering of permitted APIC ID targets at
all).

If userspace actually *triggers* an IRQ with an invalid target, that
will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range
check.

If KVM enforced that the IRQ target must be valid at the time it is
*configured*, that would force userspace to create all vCPUs and do
various other parts of setup (in this case, setting the Xen long_mode)
before restoring the IRQ table.

Cc: stable@...r.kernel.org
Signed-off-by: David Woodhouse <dwmw@...zon.co.uk>
---
 arch/x86/kvm/xen.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 38b33cdd4232..2a593db2ea3f 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -1970,8 +1970,18 @@ int kvm_xen_setup_evtchn(struct kvm *kvm,
 {
 	struct kvm_vcpu *vcpu;
 
-	if (ue->u.xen_evtchn.port >= max_evtchn_port(kvm))
-		return -EINVAL;
+	/*
+	 * No check for being within range of max_evtchn_port() here.
+	 * Userspace can configure what ever targets it likes; they
+	 * just won't be delivered if/while they're invalid. Just like
+	 * userspace can configure MSIs which target non-existent APICs.
+	 * This means that on Live Migration and Live Update, the IRQ
+	 * routing table and be restored *independently* of other things
+	 * like creating vCPUs without imposing an ordering dependency on
+	 * userspace. In this particular case, the problematic ordering
+	 * would be with setting the Xen 'long mode' flag which changes
+	 * max_evtchn_port() to allow 4096 instead of 1024 event channels.
+	 */
 
 	/* We only support 2 level event channels for now */
 	if (ue->u.xen_evtchn.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL)
-- 
2.49.0



Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ