linux-kernel - Re: [PATCH] irqchip/gic: prevent buffer overflow in gic_ipi_send

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: <86y1406j7d.wl-maz@kernel.org>
Date: Tue, 10 Sep 2024 08:50:30 +0100
From: Marc Zyngier <maz@...nel.org>
To: Sergey Shtylyov <s.shtylyov@....ru>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] irqchip/gic: prevent buffer overflow in gic_ipi_send_mask()

On Mon, 09 Sep 2024 20:23:21 +0100,
Sergey Shtylyov <s.shtylyov@....ru> wrote:
> 
> On 9/5/24 10:29 AM, Thomas Gleixner wrote:
> [...]
> 
> >> ARM GIC arch v2 spec claims support for just 8 CPU interfaces.  However,
> >> looking at the GIC driver's irq_set_affinity() method, it seems that the
> >> passed CPU mask may contain the logical CPU #s beyond 8, and that method
> 
>    s/8/7/, of course... :-<
> 
> >> filters them out before reading gic_cpu_map[], bailing out with
> >> -EINVAL.
> > 
> > The reasoning is correct in theory, but in reality it's a non problem.
> 
>    Frankly, before finalizing this patch I had tried to ascertain whether
> cpumask could contain CPUs with the logical #s higher than 8 but that was
> taking way too much time and I gave up... :-)

You can't really work it out form the source code. The trick is that
the integration requirements prevent you from doing so. It is as
simple as that. People have built GICv2-like interrupt controllers
with more than 8 CPUs, but it is a different beast (see the hip04
driver for a good laugh).

Another possible hack is to have 2 GICs side by side, and connect up
to 8 CPUs to each. But then you cannot IPI one cluster from another,
and you end-up with the hilarious situation that plagued the Axxia
SoC, which Linux never really supported, because this is utter
nonsense.

> 
> > Simply because processors which use this GIC version cannot have more
> > than 8 cores.
> 
>    And big.LITTLE not involved?

In what sense? Asymmetric configurations don't impact the number of
CPU interfaces that can be connected to a single GIC.

> 
> > That means num_possible_cpus() <= 8 so the cpumask handed in cannot have
> > bits >= 8 set. Ergo for_each_cpu() can't return a bit which is >= 8.
> 
>    Perhaps adding WARN_ON() would make some sense though? :-)

But why? If someone builds something that cannot work, they have
bigger problems than an extra bit in a bitmap, and the kernel is not a
validation suite for idiotic integration (though I wonder at times).

	M.

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