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

Reply via email to