Hi On Thu, Mar 12, 2015 at 4:57 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote: > В Wed, 11 Mar 2015 18:50:23 +0100 > Kay Sievers <k...@vrfy.org> пишет: > >> On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy <li...@colorremedies.com> >> wrote: >> > 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. >> >> With systemd-boot, there will be no config to sign: >> >> https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/ >> > > How exactly putting files in a container solves the problem that they > are not signed? This is not quite obvious from blog post.
The config/etc. snippets are now part of the _signed_ EFI binary, which is always verified by the firmware. Therefore, we don't need to verify the other snippets separately. Thanks David _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
