On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann <dh.herrm...@gmail.com> wrote: > 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.
Where signing key comes from? Is this key generated by user on end system and enrolled in firmware? > > Thanks > David _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
