linux-kernel - Re: [PATCH] MIPS: fw: Gracefully handle unknown firmware protocols

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: <alpine.DEB.2.21.2408252029130.30766@angie.orcam.me.uk>
Date: Sun, 25 Aug 2024 20:59:26 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Bjørn Mork <bjorn@...k.no>
cc: Jiaxun Yang <jiaxun.yang@...goat.com>, 
    Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, 
    linux-kernel@...r.kernel.org, 
    "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] MIPS: fw: Gracefully handle unknown firmware protocols

On Sun, 25 Aug 2024, Bjørn Mork wrote:

> >  U-Boot isn't the only firmware used with MIPS systems, and in fact it's 
> > quite a recent addition; e.g. DEC REX and SGI ARCS firmware goes back at 
> > least to 1990 and we continue supporting these systems.  There's also CFE, 
> > PMON, YAMON, etc.
> 
> I know.  That's what I'm trying to make us support :-)
> 
> We can't blindly assume that all those firmwares implement the exact
> same command line and environment protocol as U-Boot.  Yamon obviously
> uses something similar enough.  But what about the others?

 I can see `fw_init_cmdline' is only used for a handful of newer platforms 
and other ones handle it differently (e.g. arch/mips/dec/prom/cmdline.c).  
Even those that do use the function have a choice to override the default 
handler by setting CONFIG_HAVE_PLAT_FW_INIT_CMDLINE.  Perhaps it's what 
you need to do for your platform too.

 Also lots of MIPS platforms have used `prom_getenv' since long before 
`fw_getenv' and arch/mips/fw/lib/cmdline.c have been added and I have no 
idea why a competing interface was let in back in 2013 with disregard to 
the existing infrastructure.  There is `cfe_getenv' for CFE platforms too. 

 It's clear to me that this mess has to be cleaned up.  Not all kinds of 
firmware permit the setting of arbitrary environment variables (or ones 
that survive a reboot) though.

  Maciej