linux-kernel - Re: [PATCH] irqchip/gic-v4.1: Properly lock VPEs when doing a directLPI invalidation

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:   Mon, 03 Jul 2023 19:54:01 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Zenghui Yu <yuzenghui@...wei.com>
Cc:     <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kunkun Jiang <jiangkunkun@...wei.com>,
        <wanghaibin.wang@...wei.com>
Subject: Re: [PATCH] irqchip/gic-v4.1: Properly lock VPEs when doing a directLPI invalidation

On Thu, 29 Jun 2023 15:52:24 +0100,
Zenghui Yu <yuzenghui@...wei.com> wrote:
> 
> Hi Marc,
> 
> On 2023/6/17 15:32, Marc Zyngier wrote:
> > We normally rely on the irq_to_cpuid_[un]lock() primitives to make
> > sure nothing will change col->idx while performing a LPI invalidation.
> 
> "change col_idx while performing a vLPI invalidation"?
> 
> > However, these primitives do not cover VPE doorbells, and we have
> > some open-coded locking for that. Unfortunately, this locking is
> > pretty bogus.
> > 
> > Instead, extend the above primitives to cover VPE doorbells and
> > convert the whole thing to it.
> > 
> > Fixes: f3a059219bc7 ("irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access")
> > Reported-by: Kunkun Jiang <jiangkunkun@...wei.com>
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> > Cc: Zenghui Yu <yuzenghui@...wei.com>
> > Cc: wanghaibin.wang@...wei.com
> 
> Reviewed-by: Zenghui Yu <yuzenghui@...wei.com>

Thanks!

> 
> Nit: I think the Subject header can be changed to 'irqchip/gic-v4' as
> the bug it fixes only affects GICv4 HW. v4.1 is unaffected.

I'm not so sure.

v4.0 didn't allow direct invalidation of VPE doorbells (we had to use
the fake device hack), except for the HiSi special that implemented
DirectLPI despite the presence of multiple ITSs. It was a violation of
the architecture, but it really saved the day by making invalidations
cheap enough.

Only with v4.1 did we get architectural support for doorbell
invalidation via a register instead of a command for a fake device.

So as far as the architecture is concerned, this should only affect
v4.1. As a side effect, it also affect HiSi's v4.0 implementations.

Or am I missing something?

Cheers,

	M.

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