linux-kernel - Re: [PATCH 1/3] arm64: Disable GiC priorities on Mediatek devices w/ firmware issues

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: <20231107101812.GC18944@willie-the-truck>
Date:   Tue, 7 Nov 2023 10:18:12 +0000
From:   Will Deacon <will@...nel.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Mark Rutland <mark.rutland@....com>, Marc Zyngier <maz@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Chen-Yu Tsai <wenst@...omium.org>,
        Amit Daniel Kachhap <amit.kachhap@....com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        James Morse <james.morse@....com>,
        Joey Gouly <joey.gouly@....com>,
        Mark Brown <broonie@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 1/3] arm64: Disable GiC priorities on Mediatek devices w/
 firmware issues

On Mon, Oct 30, 2023 at 04:19:55PM -0700, Doug Anderson wrote:
> On Wed, Oct 18, 2023 at 4:01 AM Mark Rutland <mark.rutland@....com> wrote:
> > On Fri, Oct 06, 2023 at 03:15:51PM -0700, Douglas Anderson wrote:
> > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > > index 2806a2850e78..e35efab8efa9 100644
> > > --- a/arch/arm64/kernel/cpufeature.c
> > > +++ b/arch/arm64/kernel/cpufeature.c
> > > @@ -2094,9 +2094,30 @@ static int __init early_enable_pseudo_nmi(char *p)
> > >  }
> > >  early_param("irqchip.gicv3_pseudo_nmi", early_enable_pseudo_nmi);
> > >
> > > +static bool are_gic_priorities_broken(void)
> > > +{
> > > +     bool is_broken = false;
> > > +     struct device_node *np;
> > > +
> > > +     /*
> > > +      * Detect broken Mediatek firmware that doesn't properly save and
> > > +      * restore GIC priorities.
> > > +      */
> > > +     np = of_find_compatible_node(NULL, NULL, "arm,gic-v3");
> > > +     if (np) {
> > > +             is_broken = of_property_read_bool(np, "mediatek,broken-save-restore-fw");
> > > +             of_node_put(np);
> > > +     }
> > > +
> > > +     return is_broken;
> > > +}
> >
> > I'm definitely in favour of detecting this in the cpucap, but I think it'd be
> > better to parse the DT once on the boot CPU rather than on each CPU every time
> > it's brought up.
> >
> > I think if we add something like:
> >
> > #ifdef CONFIG_ARM64_PSEUDO_NMI
> > static void detect_system_supports_pseudo_nmi(void)
> > {
> >         struct device_node *np;
> >
> >         if (!enable_pseudo_nmi)
> >                 return;
> >
> >         /*
> >          * Detect broken Mediatek firmware that doesn't properly save and
> >          * restore GIC priorities.
> >          */
> >         np = of_find_compatible_node(NULL, NULL, "arm,gic-v3");
> >         if (np && of_property_read_bool(np, "mediatek,broken-save-restore-fw")) {
> >                 pr_info("Pseudo-NMI disabled due to Mediatek Chromebook GICR save problem");
> >                 enable_pseudo_nmi = false;
> >         }
> >         of_node_put(np);
> > }
> > #endif /* CONFIG_ARM64_PSEUDO_NMI */
> > static inline void detect_system_supports_pseudo_nmi(void) { }
> > #endif
> >
> > ... then we can call that from init_cpu_features() before we call
> > setup_boot_cpu_capabilities(), and then the existing logic in
> > can_use_gic_priorities() should just work as that returns the value of
> > enable_pseudo_nmi.
> >
> > Note: of_node_put(NULL) does nothing, like kfree(NULL), so it's fine for that
> > to be called in the !np case.
> >
> > Would you be happy to fold that in? I'm happy with a Suggested-by tag if so. :)
> 
> Yup, that looks good to me and I can fold it in (fixing a few nits
> like missing "\n" and adding __init to the function). I'll wait to get
> maintainers opinions on whether to fold patch #3 in here and then send
> a v2.

No preference from me; I assume this stuff's all going in together anyway.

Will