linux-kernel - Re: [PATCH] MIPS: smp-mt: enable all hardware interrupts on second VPE

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]

Message-ID: <0dbe47388183bf17830e5c77513ca78c58e32612.camel@svanheule.net>
Date:   Mon, 01 Aug 2022 18:02:38 +0200
From:   Sander Vanheule <sander@...nheule.net>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     Marc Zyngier <maz@...nel.org>,
        Aleksander Jan Bajkowski <olek2@...pl>,
        Hauke Mehrtens <hauke@...ke-m.de>, git@...ger-koblitz.de,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: smp-mt: enable all hardware interrupts on second
 VPE

Hi Thomas,

On Mon, 2022-08-01 at 17:25 +0200, Thomas Bogendoerfer wrote:
> On Thu, Jul 28, 2022 at 05:50:10PM +0200, Martin Blumenstingl wrote:
> > I think for the Realtek SoC's this would be problematic because it's
> > using MIPS_GENERIC. My understanding is that in an ideal world all
> 
> which SOC are these ?

That would be the SoCs supported by MACH_REALTEK_RTL. More specifically, the
ones affected by this issue are the RTL8391M, RTL8392M, RTL8393M, and RTL8396M
which have two VPEs.

The SoC interrupt controller on these chips can route interrupts to all CPU HW
interrupts. If only IP6 and IP7 are enabled on the second VPE, anything routed
there to IP2-IP5 ends up in a black hole.

Best,
Sander

> 
> > platforms would switch to MIPS_GENERIC.
> > As an alternative to making irq-mips-cpu capable of changing another
> > CPU's registers: would you also be happy with a change that implements
> > the following idea (pseudocode) in vsmp_init_secondary():
> >     struct device_node *root_node = of_find_node_by_path("/");
> > 
> >     if (mips_gic_present() ||
> >         of_device_is_compatible(root_node, "lantiq,xrx200") ||
> >         of_device_is_compatible(root_node, "realtek,some-relevant-soc"))
> >         change_c0_status(ST0_IM, STATUSF_IP2 | STATUSF_IP3 |
> >             STATUSF_IP4 | STATUSF_IP5 |
> >             STATUSF_IP6 | STATUSF_IP7);
> >     else
> >        ...
> > 
> >     of_node_put(root_node);
> > 
> > That way we don't risk enabling interrupt lines which shouldn't be
> > enabled (on SoCs which we don't know).
> > And also it would not cause any issues with MIPS_GENERIC support.
> 
> well it's not exactly the abstraction I'm looking for, but it's ok for me
> as a short term way to move forward.
> 
> Thomas.
>