linux-kernel - Re: Re: Thinking about firmware and hardware description for latest Rockchip platforms

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: <20241023173514.4538-1-shimrrashai@gmail.com>
Date: Wed, 23 Oct 2024 12:35:14 -0500
From: Shimrra Shai <shimrrashai@...il.com>
To: dsimic@...jaro.org
Cc: linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	shimrrashai@...il.com
Subject: Re: Re: Thinking about firmware and hardware description for latest Rockchip platforms

On 2024-10-23  2:46, Dragan Simic wrote:
> As you noted already, the DT definitions are fixed and improved
> all the time, which is actually great.  However, the backward
> compatibility is ensured, because newer kernels are guaranteed
> to work with older DTs, which doesn't mean that the board DTs
> provided through firmware should become frozen in any way, as
> explained further below.

Thanks - my concern was about backward compatibility so that if some
user did not upgrade their FW but then tried to install a *newer*
Linux found things mysteriously breaking due to that some DT revision
in code had broken the backwards compatibility. Of course that could
also be considered a bug, even while new FWs could/would still be
rolled out.

> Freezing anything would be simply wrong.  It might look good from
> the perspective of having something "stable", which is similar to
> how x86_64 firmware works on PC motheboards, but the continual
> bugfixes and improvements are actually extremely good, because
> they prevent various ARM boards from effectively becoming abandoned,
> which is unfortunately rather usual with x86_64 motherboards that
> become so "stable" that some nasty firmware bugs are never fixed
> and their users are left high and dry.

Yes, I'm not against new FW upgrades, just the idea of users *having*
to upgrade their FW simply because a new kernel came out when nothing
like that is typical on x86 or at least in my experience using it over
many years).

Note that the situation of a DT upgrade that is obtained by FW
upgrade breaking older kernels, i.e. broken *forward* compatibility of
the older kernel with later DT, isn't so much a problem because we can
simply keep the older DT in the FW when issuing the FW upgrade, as I
believe there is a facility for supporting multiple, versioned DTs in
that UEFI package [and if not, it could easily be added]. It's the
backward compatibility that is my issue because reflashing FW, even
though not too hard on these boards, is perhaps more heady for your
average PC or smartphone user.

That is to say, I'm imagining the case of bundled computers
pre-shipped with the loaded FW and OS installed as usual and someone
says "hey they got a new Ubuntu [or whatever], let's install it!" BAM,
devices stop working because they did not upgrade FW, forcing an FW
upgrade in a way an x86 user would not be similarly forced. Though of
course, that could then be reasonably called a regression bug (as it
would appear from the user's perspective, not knowing about the FW
change), if backwards compatibility is indeed already a long-standing
policy (and is really what I was after with that "freeze" suggestion
even if it itself would not be the way to get it).

 - Shimrra Shai