Hi Francesco, francesco@xxxxxxxxxx wrote on Fri, 16 Dec 2022 17:30:18 +0100: > On Fri, Dec 16, 2022 at 04:35:01PM +0100, Miquel Raynal wrote: > > marex@xxxxxxx wrote on Fri, 16 Dec 2022 15:32:28 +0100: > > > The second part of the message, as far as I understand it, is > > > "ignore problems this will cause to users of boards we do not know > > > about, let them run into unbootable systems after some linux kernel > > > update, > > > > Now you know what kernel update will break them, so you can prevent it > > from happening. > > > > For boards without even a dtsi in the kernel, should we care? > > Would caring for those boards not be just exact the same as caring for > some UEFI/ACPI mess for which no source code is normally available and > nobody really known at which point the various vendors have forked their > source code from some Intel or AMD or whatever reference code? I am sorry I don't know UEFI/ACPI well enough to discuss it. > IMHO we should care for the multiple reason I have already written in my > previous emails. > > And honestly, just as a side comment, I would feel way more happy > to know that the elevator control system in the elevator I use everyday > or the chemical industrial plan HMI next to my home is running an up to > date Linux system that is not affected by known security vulnerabilities > and they did stop updating it just because there was some random bug > preventing the updated kernel to boot and nobody had the time/skill to > investigate and fix it. [1] The issue comes from a very specific U-Boot function that should have never existed. I hope people working on chemical plants do not make use of these and will not disregard the "your DT is broken there [...]" warning we plan to add right before their updated board will fail. We are not living people in the dark, I agreed for a warning, but I don't think applying the proposed fix blindly is wise and future-proof. Thanks, Miquèl
