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: <867caq6r73.wl-maz@kernel.org>
Date: Thu, 03 Oct 2024 00:05:52 +0100
From: Marc Zyngier <maz@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Kunkun Jiang <jiangkunkun@...wei.com>
Subject: Re: [PATCH] irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

On Wed, 02 Oct 2024 23:17:02 +0100,
Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> On Wed, Oct 02 2024 at 21:49, Marc Zyngier wrote:
> > Kunkun Jiang reports that there is a small window of opportunity for
> > userspace to force a change of affinity for a VPE while the VPE has
> > already been unmapped, but the corresponding doorbell interrupt still
> > visible in /proc/irq/.
> >
> > Plug the race by checking the value of vmapp_count, which tracks whether
> > the VPE is mapped ot not, and returning an error in this case.
> >
> > This involves making vmapp_count common to both GICv4.1 and its v4.0
> > ancestor.
> >
> > Reported-by: Kunkun Jiang <jiangkunkun@...wei.com>
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> > Link: https://lore.kernel.org/r/c182ece6-2ba0-ce4f-3404-dba7a3ab6c52@huawei.com
> 
> I assume this wants a Fixes: tag and a cc: stable, no?

Unclear.

While this is clearly a bug, the architectural effects are not fatal,
and nothing goes really wrong. However, some implementations are
reporting this as a RAS error. That's a bit silly, because this isn't
indicative of HW rotting away, and only a sure way to shoot yourself
in the foot. That's the real bug IMO.

So if these people are really hung up on having this addressed in
prehistoric kernels, we can always add:

Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")

which points to the commit that implements the infrastructure we're
relying on. GICv4.0, which predates the above by at least a couple of
years is also affected, but nobody really cares about that.

Thanks,

	M.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ