Re: [RFC] initoverlayfs - a scalable initial filesystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux