linux-kernel - Re: [bug report] GICv4.1: vSGI remains pending across the guest reset

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

Date: Sun, 17 Dec 2023 18:52:55 +0000
From: Marc Zyngier <maz@...nel.org>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: Kunkun Jiang <jiangkunkun@...wei.com>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Jean-Philippe Brucker <jean-philippe@...aro.org>,
	"moderated list:ARM SMMU DRIVERS" <linux-arm-kernel@...ts.infradead.org>,
	kvmarm@...ts.linux.dev,
	open list <linux-kernel@...r.kernel.org>,
	"wanghaibin.wang@...wei.com" <wanghaibin.wang@...wei.com>
Subject: Re: [bug report] GICv4.1: vSGI remains pending across the guest reset

On Sun, 17 Dec 2023 17:34:38 +0000,
Oliver Upton <oliver.upton@...ux.dev> wrote:
> 
> On Sun, Dec 17, 2023 at 05:33:16PM +0000, Oliver Upton wrote:
> > On Sun, Dec 17, 2023 at 11:26:15AM +0000, Marc Zyngier wrote:
> > 
> > [...]
> > 
> > > But this has *nothing* to do with the guest. This is the *host*
> > > userspace performing a write to the redistributor view, which has
> > > different semantics. Which is why your earlier description made no
> > > sense to me.
> > > 
> > > I think the problem is slightly larger than what you describe. A write
> > > to ISPENDR0 should be propagated to the ITS for any values of the
> > > latch, just like this happens on enabling HW-backed SGIs.
> > > 
> > > Can you please give this a go?
> > 
> > What do you think about using this as an opportunity for a bit of
> > cleanup? It'd be nice unify the various MMIO and uaccess handlers for
> > SPENDING + CPENDING while being careful about the arch_timer interrupt.

What is special about the timer interrupt?

> Cut myself off... Meant to say that user writes to SPENDING for GICv3
> can then be treated as:
> 
> > 	clear = ~val;
> > 	vgic_uaccess_write_spending(val);
> > 	vgic_uaccess_write_cpending(clear);

Could be. But I'd rather have separate fixes from more invasive
reworks.  Specially given that we have had multiple ugly bugs around
this code in the past, which is why we ended up splitting userspace
from guest accessors.

	M.

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