linux-kernel - Re: [PATCH] firmware: arm_scmi: Relax BASE protocol sanity checks on protocol list

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, 06 Jun 2022 16:55:10 +0200
From:   Heiko Stübner <heiko@...ech.de>
To:     Cristian Marussi <cristian.marussi@....com>,
        Sudeep Holla <sudeep.holla@....com>
Cc:     Michael Riesch <michael.riesch@...fvision.net>,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Liang Chen <cl@...k-chips.com>,
        Kever Yang <kever.yang@...k-chips.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Jeffy Chen <jeffy.chen@...k-chips.com>,
        Peter Geis <pgwipeout@...il.com>,
        Nicolas Frattaroli <frattaroli.nicolas@...il.com>,
        Etienne Carriere <etienne.carriere@...aro.org>
Subject: Re: [PATCH] firmware: arm_scmi: Relax BASE protocol sanity checks on protocol list

Am Montag, 6. Juni 2022, 16:43:05 CEST schrieb Sudeep Holla:
> On Mon, Jun 06, 2022 at 02:31:48PM +0100, Cristian Marussi wrote:
> > On Mon, Jun 06, 2022 at 02:59:10PM +0200, Michael Riesch wrote:
> > > Hi Cristian,
> > >
> > Hi Michael,
> >
> > > On 5/23/22 19:15, Cristian Marussi wrote:
> > > > Even though malformed replies from firmware must be treated carefully to
> > > > avoid memory corruption Kernel side, some out-of-spec SCMI replies can
> > > > be tolerated to avoid breaking existing deployed system, as long as they
> > > > won't cause memory issues.
> > > >
> > > > Reported-by: Nicolas Frattaroli <frattaroli.nicolas@...il.com>
> > > > Cc: Etienne Carriere <etienne.carriere@...aro.org>
> > > > Cc: Sudeep Holla <sudeep.holla@....com>
> > > > Signed-off-by: Cristian Marussi <cristian.marussi@....com>
> > >
> > > Thanks a lot, without this fix the Mali G52 GPU won't probe on my RK3568
> > > EVB1 in vanilla v5.19-rc1.
> > >
> >
> > Yes, the break was reported on -next and today it appeared in 5.19-rc1.
> > A proper FW fix is also up for review by Etienne but in the meantime
> > this tries to limit damages relaxing a bit the checks.
> >
> > > I guess this patch should have a Fixes: tag, right?
> > >
> >
> > It has not a Fixes tag because the issue was introduced in 5.19-rc1 and the
> > fix will go in with the next round of v5.19 fixes by Sudeep (AFAIU) so it
> > will be solved within the v5.19 cycle and I thought the Fixes tag was
> > not needed in this case (I could be wrong...)
> 
> Correct, if for some reason, we can't push this before v5.19, then fixes
> tag needs to added. I will add that then, but for now let us target getting
> it in before v5.19

hmm, I'd disagree for the generalization.

While true that is not 100% necessary to be present in all cases, so
definitly no reason for a new version when applied to the same -rc series,
having the Fixes tag not only clearly marks the patch as such, but also
allows people reading either mailing lists or the later the git history
to actually see where the issue started. So I really think it is a
nice-to-have in most cases.


Heiko