linux-kernel - [tip: irq/urgent] irqchip/gic-v3: Force propagation of the active state with a read-back

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <173093595604.32228.1931318188286510625.tip-bot2@tip-bot2>
Date: Wed, 06 Nov 2024 23:32:36 -0000
From: "tip-bot2 for Marc Zyngier" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Christoffer Dall <christoffer.dall@....com>, Marc Zyngier <maz@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>, stable@...r.kernel.org, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: [tip: irq/urgent] irqchip/gic-v3: Force propagation of the active
 state with a read-back

The following commit has been merged into the irq/urgent branch of tip:

Commit-ID:     464cb98f1c07298c4c10e714ae0c36338d18d316
Gitweb:        https://git.kernel.org/tip/464cb98f1c07298c4c10e714ae0c36338d18d316
Author:        Marc Zyngier <maz@...nel.org>
AuthorDate:    Wed, 06 Nov 2024 08:44:18 
Committer:     Thomas Gleixner <tglx@...utronix.de>
CommitterDate: Thu, 07 Nov 2024 00:22:44 +01:00

irqchip/gic-v3: Force propagation of the active state with a read-back

Christoffer reports that on some implementations, writing to
GICR_ISACTIVER0 (and similar GICD registers) can race badly with a guest
issuing a deactivation of that interrupt via the system register interface.

There are multiple reasons to this:

 - this uses an early write-acknoledgement memory type (nGnRE), meaning
   that the write may only have made it as far as some interconnect
   by the time the store is considered "done"

 - the GIC itself is allowed to buffer the write until it decides to
   take it into account (as long as it is in finite time)

The effects are that the activation may not have taken effect by the time
the kernel enters the guest, forcing an immediate exit, or that a guest
deactivation occurs before the interrupt is active, doing nothing.

In order to guarantee that the write to the ISACTIVER register has taken
effect, read back from it, forcing the interconnect to propagate the write,
and the GIC to process the write before returning the read.

Reported-by: Christoffer Dall <christoffer.dall@....com>
Signed-off-by: Marc Zyngier <maz@...nel.org>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Acked-by: Christoffer Dall <christoffer.dall@....com>
Cc: stable@...r.kernel.org
Link: https://lore.kernel.org/all/20241106084418.3794612-1-maz@kernel.org

---
 drivers/irqchip/irq-gic-v3.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index ce87205..8b6159f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -524,6 +524,13 @@ static int gic_irq_set_irqchip_state(struct irq_data *d,
 	}
 
 	gic_poke_irq(d, reg);
+
+	/*
+	 * Force read-back to guarantee that the active state has taken
+	 * effect, and won't race with a guest-driven deactivation.
+	 */
+	if (reg == GICD_ISACTIVER)
+		gic_peek_irq(d, reg);
 	return 0;
 }