[Sorry for the spam to the people in Cc. Now the real address.] Dear Luca, Am 11.12.23 um 22:45 schrieb Luca Boccassi: > On Mon, 11 Dec 2023 at 21:20, Demi Marie Obenour wrote: >> >> On Mon, Dec 11, 2023 at 08:58:58PM +0000, Luca Boccassi wrote: >>> On Mon, 11 Dec 2023 at 20:43, Demi Marie Obenour wrote: >>>> On Mon, Dec 11, 2023 at 08:15:27PM +0000, Luca Boccassi wrote: >>>>> On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenour >>>>>> On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote: >>>>>>> On Fr, 08.12.23 17:59, Eric Curtin (ecurtin@xxxxxxxxxx) wrote: […] >>>>> And for ancient, legacy platforms that do not support modern APIs, the >>>>> old ways will still be there, and can be used. Nobody is going to take >>>>> away grub and dracut from the internet, if you got some special corner >>>>> case where you want to use it it will still be there, but the fact >>>>> that such corner cases exist cannot stop the rest of the ecosystem >>>>> that is targeted to modern hardware from evolving into something >>>>> better, more maintainable and more straightforward. >>>> >>>> The problem is not that UEFI is not usable in automotive systems. The >>>> problem is that U-Boot (or any other UEFI implementation) is an extra >>>> stage in the boot process, slows things down, and has more attack >>>> surface. >>> >>> Whatever firmware you use will have an attack surface, the interface >>> it provides - whether legacy bios or uefi-based - is irrelevant for >>> that. Skipping or reimplementing all the verity, tpm, etc logic also >>> increases the attack surface, as does adding initrd-only code that is >>> never tested and exercised outside of that limited context. If you are >>> running with legacy bios on ancient hardware you also will likely lack >>> tpm, secure boot, and so on, so it's all moot, any security argument >>> goes out of the window. If anybody cares about platform security, then >>> a tpm-capable and secureboot-capable firmware with a modern, usable >>> interface like uefi, running the same code in initrd and full system, >>> using dm-verity everywhere, is pretty much the best one can do. >> >> Neither Chrome OS devices nor Macs with Apple silicon use UEFI, and both >> have better platform security than any UEFI-based device on the market I >> am aware of. > > We are talking about Linux distributions here. If one wants to use > proprietary systems, sure, there are better things out there, but > that's off topic. In what way is ChromeOS more proprietary than the other GNU/Linux distributions, that allow to install the Chrome browser? Kind regards, Paul
