On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger <tobias.hun...@gmail.com> wrote: >> If you're concerned about bootloader configuration modification as a >> threat vector, then it needs to go on an encrypted volume. This >> suggests an initial bootloader configuration that only enables the >> user to supply a passphrase/key file to unlock that volume, and then >> load a new bootloader configuration file. > > I am still hoping secure boot and sd-boot will solve this issue > mid-term by making sure all the early boot components are signed > properly.
The bootloader configuration files aren't signed. Maybe the should be. And maybe done away with in favor of dynamic discovery and "hot" keys for indicating common boot options. Any general purpose solution should account for degraded bootable raid, which means each ESP needs to be identical. Either each ESP bootloader looks to a single location on raid for configuration, or uses dynamic discovery, or some system of sequentially updating each ESP needs to be devised. -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
