[systemd-devel] How to factory reset?

Tom Gundersen teg at jklm.no
Thu Mar 12 07:11:31 PDT 2015

On Thu, Mar 12, 2015 at 2:41 PM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> On Thu, Mar 12, 2015 at 4:24 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>> Hi
>> On Thu, Mar 12, 2015 at 2:06 PM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
>>> On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>>>>>> 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?
>> This is the key used by EFI secure boot. We don't change the semantics
>> in any way.
>> (yes, the key can be provided by the machine owner and stored in
>> firmware, please see EFI specs for information)
> I know how secure boot works. You misunderstand the question.
> initrd and cmdline are volatile and generated on end-user system. So
> your container must be signed on end user system. End user obviously
> does not have Microsoft or vendor private keys to sign your container,
> so end user must manage own keys. Apparently, it is not quite as
> simple, otherwise we would not need to invent shim in the first place.
> So how do you envision signing of container in practice?

In case this was not clear: we envision signed containers (including
static cmdline and initrd) being provided by the vendor. This means we
need general purpose initrd's and cmdline's that will work without
modification on generic systems (which dracut can give us).

If people want to roll their own initrd/commandline and still use
secure boot, they can still do that, but then they have to sign it
themselves (with their own key, which they must enroll, etc).



More information about the systemd-devel mailing list