Discussion:
How to factory reset?
(too old to reply)
Tobias Hunger
2015-03-09 11:02:57 UTC
Permalink
Hi everybody,

I am running a kiosk-like box here and have a read-only copy of /etc
hidden away in /usr/ somewhere. /etc is a symlink to that directory
and that works fine.

Recently I thought I'd experiment with factory reset. My idea was to
use a tmpfs mounted on /etc instead of that symlink and populate that
from the directory in /usr on boots. That way I can still experiment
with changes to the configuration, but on all reboots I get the
trusted state back.

So how is factory reset supposed to work is systemd?


My first attempt was to add a etc.mount unit to mount a tmpfs over
/etc, modeled after the tmp.mount unit shipped with systemd and then
use a tmpfiles.d snippet to copy the actual configuration. This seems
pretty close to the ideas floating around in some blog posts on the
topic of factory reset.

Unfortunately this does not work: By the time /etc gets mounted
something already puts files into the empty /etc. The culprit seems to
be ldconfig.service. There are some more files that are in /etc
(localtime, machine-id and systemd directory), but I could not find
who creates those I think systemd-nspawn might be the one to blame for
those.

There are some more services that get started and fail because their
configuration is not there yet. The systemd-firstboot.service also
kicks in (a really nice feature by the way!), but that of course
needed to be axed for my setup.


The next step was add a service that extracts a tarball with my
configuration, modeled on systemd-firstboot.service and depending on
etc.mount. That did not improve the situation by much: The files were
still created and quite a few processes still did try to start before
/etc with their configuration was set up.


Then I started adding After= and Before= statements to the offending
services (systemd-remount-fs.service, journald.service and a few
others that I can't remember right now). With this I get
ldconfig.service and journald up and running.

Unfortunately the dbus.service will not come up, claiming that there
is no /etc/dbus-1/system.conf. This file is in the tarball, and the
output during boot-up suggests that dbus.service is started only after
the /etc-tarball is extracted, so that file should be there. There
seems to be a dbus.socket involved in the start of dbus.service and
that is started before the tarball is extracted.

At this point I am stuck. Do I need to have dbus.socket wait for my
etc-extract.service? Or why would dbus not see the configuration file?


Am I on the right track with adding Before= and After= statements to
various services? Is there some convenient target that I should use
instead? Something that needs to be reached before systemd starts to
bring up services?

Should I take a different approach entirely and e.g. populate /etc in
the initrd? I'd like to keep the initrd generic if I can, so I am not
happy with that idea.

I am using systemd-nspawn for my experiments. This seems to add some
files to /etc, which is not ideal, but does not seem to hurt too much
either. Is there a better way to test setups like the one I intend to
get?

Does systemd-nspawn indeed add/change files in /etc of the directory
it is running from?

Best Regards,
Tobias
Lennart Poettering
2015-03-10 16:01:15 UTC
Permalink
Post by Tobias Hunger
Hi everybody,
I am running a kiosk-like box here and have a read-only copy of /etc
hidden away in /usr/ somewhere. /etc is a symlink to that directory
and that works fine.
Recently I thought I'd experiment with factory reset. My idea was to
use a tmpfs mounted on /etc instead of that symlink and populate that
from the directory in /usr on boots. That way I can still experiment
with changes to the configuration, but on all reboots I get the
trusted state back.
So how is factory reset supposed to work is systemd?
So you want not just factory reset, but actually a stateless system,
where every single boot is basically a factory reset?

My recommendation would be to set this up within the initrd: mount a
tmpfs as /, then mount the physical /usr into it and transition to the
host OS.

There's currently no explicit support for this to make this easy from the
initrd. (It is available in nspawn though with the --volatile=)
switch. But it's on the todo list to add that, so that what I describe
above is easily available. We also should provide a scheme that one
can flush /etc explicitly ones for a factory reset, via a kernel
cmdline option.

That said, I figure it should suffice to add entries for / and /usr to
the fstab and get the initrd to make use of it.
Post by Tobias Hunger
Unfortunately the dbus.service will not come up, claiming that there
is no /etc/dbus-1/system.conf. This file is in the tarball, and the
output during boot-up suggests that dbus.service is started only after
the /etc-tarball is extracted, so that file should be there. There
seems to be a dbus.socket involved in the start of dbus.service and
that is started before the tarball is extracted.
Yes, dbus is currently not compatible with stateless bootups. PAM is
neither. For PAM we ship a tmpfiles snippet to work around this, for
dbus we don't though, since kdbus kinda makes the problem go away...
Post by Tobias Hunger
Should I take a different approach entirely and e.g. populate /etc in
the initrd? I'd like to keep the initrd generic if I can, so I am not
happy with that idea.
I am using systemd-nspawn for my experiments. This seems to add some
files to /etc, which is not ideal, but does not seem to hurt too much
either. Is there a better way to test setups like the one I intend to
get?
nspawn's --volatile= switch is how i did most of my own testing...
Post by Tobias Hunger
Does systemd-nspawn indeed add/change files in /etc of the directory
it is running from?
Well, nspawn isn't. But systemd will, if it finds /etc empty. It will
create a machine ID, and apply presets and stuff...

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2015-03-10 16:58:13 UTC
Permalink
Post by Lennart Poettering
Yes, dbus is currently not compatible with stateless bootups. PAM is
neither. For PAM we ship a tmpfiles snippet to work around this, for
dbus we don't though, since kdbus kinda makes the problem go away...
In the meantime, you might be interested in
<https://bugs.freedesktop.org/show_bug.cgi?id=89280>.

S
Tobias Hunger
2015-03-10 17:13:08 UTC
Permalink
Hi Lennart,

thanks for taking the time to answer! It is highly appreciated.

On Tue, Mar 10, 2015 at 5:01 PM, Lennart Poettering
Post by Lennart Poettering
So you want not just factory reset, but actually a stateless system,
where every single boot is basically a factory reset?
Yes, but I do have a state that I want to be applied by default at all times.
Post by Lennart Poettering
My recommendation would be to set this up within the initrd: mount a
tmpfs as /, then mount the physical /usr into it and transition to the
host OS.
That is a great idea! I was so focused on having a tmpfs on /etc that
I did not even think about that:-/

I would like to keep e.g. logs between reboots, so maybe I can just
have /var mounted from somewhere else.
Post by Lennart Poettering
There's currently no explicit support for this to make this easy from the
initrd.
There are flags to set the root filesystem and equivalent flags for
the usr one, so that should not be too hard to do.
Post by Lennart Poettering
(It is available in nspawn though with the --volatile=)
switch. But it's on the todo list to add that, so that what I describe
above is easily available. We also should provide a scheme that one
can flush /etc explicitly ones for a factory reset, via a kernel
cmdline option.
Please do not do that.

Even if all filesystems are encrypted you could factory-reset random
computers you have access to, simply by editing the bootloader
configuration file usually found in the poorly protected EFI
partition!

Better have a unit that deletes /etc before the system is shut down.
That way you at least need to have root access to the running machine
to trigger a factory reset. That keeps at least people with encrypted
drives save:-)
Post by Lennart Poettering
That said, I figure it should suffice to add entries for / and /usr to
the fstab and get the initrd to make use of it.
I do not have no stinking fstab:-)

My boxes are built up from bits and pieces of configuration. The mount
units make are just so much nicer to handle than having several pieces
edit the same file:-)
Post by Lennart Poettering
Yes, dbus is currently not compatible with stateless bootups. PAM is
neither. For PAM we ship a tmpfiles snippet to work around this, for
dbus we don't though, since kdbus kinda makes the problem go away...
I do have state for PAM, dbus and everything else, I was just not able
to get it into place in time for those services to start properly.

There are quite a few services with a condition of "writable /etc",
and with the setup I attempted /etc was writable, even before I
managed to put my tmpfs into place and extract my configuration there.
Post by Lennart Poettering
nspawn's --volatile= switch is how i did most of my own testing...
I did not use --volatile since I need to boot from an image that is
considerably different from the one on my development machine. So I
will have to set up a tmpfs manually and mount a usr there and then
just use "normal" nspawn with --directory.

Having --volatile=/path/to/usr/directory would be nice to have for the
experiments I do right now. I guess that is not so very common that it
makes sense to consider sending in a patch for that.
Post by Lennart Poettering
Well, nspawn isn't. But systemd will, if it finds /etc empty. It will
create a machine ID, and apply presets and stuff...
I *have* a machine ID and everything. Can I get that information into
place somehow *before* systemd creates all of that?


Thanks again for your reply. You did provide some food for further experiments:

1) Extract my etc-tarball to /usr/share/factory/etc and remove /etc
from the root-image. Keep the etc.mount unit.

2) Try a empty root image with my etc-tarball extracted to
/usr/share/factory/etc and no etc.mount.

3) Add var.mount to the setup of 2) to keep the logs.

With a bit of luck that should stop all the units that have a
condition on a writable /etc from getting started.

I'll get back with results:-)

Best Regards,
Tobias
Simon McVittie
2015-03-10 17:31:20 UTC
Permalink
Post by Tobias Hunger
Even if all filesystems are encrypted you could factory-reset random
computers you have access to, simply by editing the bootloader
configuration file usually found in the poorly protected EFI
partition!
If your threat model includes "an attacker can alter the partition
containing my initramfs without me noticing", then you can't win. The
attacker could equally well replace the initramfs with one that accepts
your cryptsetup password and uploads it to the internet.

For that matter, if their only goal is denial of service, they could
equally well just zero out the encrypted partitions, or their cryptsetup
key blocks - they won't know what those zeroes will decrypt to, but the
answer "not your data" is good enough for denial of service.

S
Lennart Poettering
2015-03-10 17:38:45 UTC
Permalink
Post by Tobias Hunger
Post by Lennart Poettering
So you want not just factory reset, but actually a stateless system,
where every single boot is basically a factory reset?
Yes, but I do have a state that I want to be applied by default at all times.
Well, you want the "factory defaults" to be applied when the machine
comes up, right?
Post by Tobias Hunger
Post by Lennart Poettering
My recommendation would be to set this up within the initrd: mount a
tmpfs as /, then mount the physical /usr into it and transition to the
host OS.
That is a great idea! I was so focused on having a tmpfs on /etc that
I did not even think about that:-/
I would like to keep e.g. logs between reboots, so maybe I can just
have /var mounted from somewhere else.
Hmm, currently we focussed on two models:

a) fully "volatile", meaning / as tmpfs, with /usr mounted from
physical media

b) with only "volatile" state, but persitent configuration, meaning /
mounted from physical media, and /var as tmpfs.

Your model appears to be different from that. You actually want /var
from from physical media, but /etc from tmpfs? That would be kinda the
opposite of b)...

Do you actually want all of /var mounted of physical media? If you are
interested in just logging, maybe just adding a normal mount for
/var/log/ should suffice, leaving the rest of /var on tmpfs?
Post by Tobias Hunger
Post by Lennart Poettering
(It is available in nspawn though with the --volatile=)
switch. But it's on the todo list to add that, so that what I describe
above is easily available. We also should provide a scheme that one
can flush /etc explicitly ones for a factory reset, via a kernel
cmdline option.
Please do not do that.
Even if all filesystems are encrypted you could factory-reset random
computers you have access to, simply by editing the bootloader
configuration file usually found in the poorly protected EFI
partition!
Well, if you have access to the kernel cmdline you can do whatever you
want. init=/bin/sh is infinitely more powerful than just being able to
flush out /etc...
Post by Tobias Hunger
Better have a unit that deletes /etc before the system is shut down.
That way you at least need to have root access to the running machine
to trigger a factory reset. That keeps at least people with encrypted
drives save:-)
Well, factory resets are supposed to be something that gets you back
into a defined state if you fucked up your system. In such a case it
might not be possible to boot up anymore to reset the state... Hence
having this on the kernel cmdline is kinda a necessity to make this
useful in real-life...
Post by Tobias Hunger
Having --volatile=/path/to/usr/directory would be nice to have for the
experiments I do right now. I guess that is not so very common that it
makes sense to consider sending in a patch for that.
Hmm, what precisely are you suggesting this would do?
Post by Tobias Hunger
Post by Lennart Poettering
Well, nspawn isn't. But systemd will, if it finds /etc empty. It will
create a machine ID, and apply presets and stuff...
I *have* a machine ID and everything. Can I get that information into
place somehow *before* systemd creates all of that?
presets and machined ID are applied by PID 1, before it begins with
starting any units, hence *really* early on. Note though that actually
/etc/machine-id is used as flag for "is /etc empty". If the file
exists it is assumed that /etc is provisioned properly. If it is
missing PID 1 will generate the machiend id and apply presets.

Note though that some services like ldconfig.service also want to
write to /etc, to generate some files, if they are missing... If you
want to do something before that you have to order those units
explicitly before each one of them.

Note though that much like /usr, /etc is something that we assume is
premounted when systemd is started, and where we do not support
mounting it after systemd began its work. I mean, /etc is usually
where moutns are configured, but if youw ant to mount someting on
/etc, then how is that to be found?

Hence, if you want /etc to be volatile, better do that in the initrd...
Post by Tobias Hunger
1) Extract my etc-tarball to /usr/share/factory/etc and remove /etc
from the root-image. Keep the etc.mount unit.
This will not work. Please do not work with a an etc.mount
unit. Instead do the stuff in the initrd...

Lennart
--
Lennart Poettering, Red Hat
Tobias Hunger
2015-03-10 20:33:03 UTC
Permalink
On Tue, Mar 10, 2015 at 6:38 PM, Lennart Poettering
Post by Lennart Poettering
Post by Tobias Hunger
Post by Lennart Poettering
So you want not just factory reset, but actually a stateless system,
where every single boot is basically a factory reset?
Yes, but I do have a state that I want to be applied by default at all times.
Well, you want the "factory defaults" to be applied when the machine
comes up, right?
Kind of:-) I have a somewhat strange mix of ideas taken from docker
and "Revisiting How We Put Together Linux Systems":-)

Basically I have a system a bit like docker that creates images for
all the machines I use each night:, very similar to what docker does:
You have a file, that defines some base image (which may be empty) and
allows you to further customize that image, creating a new image.

Unlike docker I create snapshots in a btrfs filesystem, mostly
following the ideas you brought forward in the "Revisiting" blog. The
end result is a "root:system:vendor:arch" and a
"usr:vendor:arch:timestamp" snapshot per physical or virtual machine I
run.

So initial install of a system is really simple: Partition the HDD,
set up a btrfs volume, copy root:s:v:a and a current usr:v:a:t over
the network, run a script that updates gummiboot based on usr:v:a:t
subvolumes found and reboot. Updates are even simpler: Copy a new
usr:v:a:t over, update gummiboot using the same script, reboot.

Currently /etc is a symlink to /usr/someplace/etc. That works well,
but has the downside that -- since /usr is mounted ro -- I can not
just experiment with different configurations anymore. Well, not
without remounting /usr rw that is.

I think I can do better with all those cool ideas like factory reset
and stateless system and such floating around:-)
Post by Lennart Poettering
a) fully "volatile", meaning / as tmpfs, with /usr mounted from
physical media
b) with only "volatile" state, but persitent configuration, meaning /
mounted from physical media, and /var as tmpfs.
Your model appears to be different from that. You actually want /var
from from physical media, but /etc from tmpfs? That would be kinda the
opposite of b)...
Yes, that is what I want.

I have a fully configured system (with that configuration stored in
/usr/someplace/etc), I want that system to reset to that configuration
regularly (in my case each time it boots), but keep the state.
Post by Lennart Poettering
Do you actually want all of /var mounted of physical media? If you are
interested in just logging, maybe just adding a normal mount for
/var/log/ should suffice, leaving the rest of /var on tmpfs?
Most of the data is in /var/log, but depending on services configured
other directories in /var might be interesting, too.

I might very well decide to deploy a mail server into a VM using my
automated setup. I can then boot that and tweak the configuration,
restarting the service as necessary. If I screw up then I want a
reboot to take me back to something that works. If I improve on the
configuration I will just update my image definition and have the
change as the default the next time I update.

I definitely do not want to loose mails by rebooting the production VM
into that updated image, so the state needs to stick around.

This is probably not a very common use-case, I admit that.
Post by Lennart Poettering
Well, factory resets are supposed to be something that gets you back
into a defined state if you fucked up your system. In such a case it
might not be possible to boot up anymore to reset the state... Hence
having this on the kernel cmdline is kinda a necessity to make this
useful in real-life...
Hmmm. Right. I assume you are going to nuking /etc without any further
user interaction, so my worry is probably unfounded.
Post by Lennart Poettering
Post by Tobias Hunger
Having --volatile=/path/to/usr/directory would be nice to have for the
experiments I do right now. I guess that is not so very common that it
makes sense to consider sending in a patch for that.
Hmm, what precisely are you suggesting this would do?
Have / of the machine be a tmpfs and mount /path/to/usr/ into as /usr
there. Forget about this, I do not think that would be widely useful
and as script fixes me up nicely:-)
Post by Lennart Poettering
presets and machined ID are applied by PID 1, before it begins with
starting any units, hence *really* early on. Note though that actually
/etc/machine-id is used as flag for "is /etc empty". If the file
exists it is assumed that /etc is provisioned properly. If it is
missing PID 1 will generate the machiend id and apply presets.
An OS installer could put the machine-id into /usr just fine (and so
can I) and systemd could just get it from there if available before
generating a new one.

It would be nice if the machine-id did not change during to a factory
reset: It is used in the logs and changing it will basically make
historical log data much harder to analyze. IIRC networkd also uses it
to generate persistent MAC addresses for containers and such.

So far this seems to be the only critical piece of information that
can not get restored via tmpfiles.d.
Post by Lennart Poettering
Note though that some services like ldconfig.service also want to
write to /etc, to generate some files, if they are missing... If you
want to do something before that you have to order those units
explicitly before each one of them.
I guess I will not have to worry about ldconfig.service. That is more
of a cache than configuration, isen't it?
Post by Lennart Poettering
Note though that much like /usr, /etc is something that we assume is
premounted when systemd is started, and where we do not support
mounting it after systemd began its work. I mean, /etc is usually
where moutns are configured, but if youw ant to mount someting on
/etc, then how is that to be found?
I was well aware of /usr being required to be available when
transitioning out of initrd. I am a bit surprised about the
requirement that /etc needs to be (partially) populated as well.

Best Regards,
Tobias
Tobias Hunger
2015-03-10 21:23:23 UTC
Permalink
Post by Tobias Hunger
Post by Lennart Poettering
presets and machined ID are applied by PID 1, before it begins with
starting any units, hence *really* early on. Note though that actually
/etc/machine-id is used as flag for "is /etc empty". If the file
exists it is assumed that /etc is provisioned properly. If it is
missing PID 1 will generate the machiend id and apply presets.
An OS installer could put the machine-id into /usr just fine (and so
can I) and systemd could just get it from there if available before
generating a new one.
It would be nice if the machine-id did not change during to a factory
reset: It is used in the logs and changing it will basically make
historical log data much harder to analyze. IIRC networkd also uses it
to generate persistent MAC addresses for containers and such.
So far this seems to be the only critical piece of information that
can not get restored via tmpfiles.d.
Thinking about this a bit longer: /usr does not seem like a good idea.
The machine-id is supposed to be unique and usr-images are meant to be
reused.

Maybe provide a kernel command line option to force the machine-id if
none is set yet?

Best Regards,
Tobias
Zbigniew Jędrzejewski-Szmek
2015-03-13 00:16:05 UTC
Permalink
Post by Tobias Hunger
Post by Tobias Hunger
Post by Lennart Poettering
presets and machined ID are applied by PID 1, before it begins with
starting any units, hence *really* early on. Note though that actually
/etc/machine-id is used as flag for "is /etc empty". If the file
exists it is assumed that /etc is provisioned properly. If it is
missing PID 1 will generate the machiend id and apply presets.
An OS installer could put the machine-id into /usr just fine (and so
can I) and systemd could just get it from there if available before
generating a new one.
It would be nice if the machine-id did not change during to a factory
reset: It is used in the logs and changing it will basically make
historical log data much harder to analyze. IIRC networkd also uses it
to generate persistent MAC addresses for containers and such.
So far this seems to be the only critical piece of information that
can not get restored via tmpfiles.d.
Thinking about this a bit longer: /usr does not seem like a good idea.
The machine-id is supposed to be unique and usr-images are meant to be
reused.
Maybe provide a kernel command line option to force the machine-id if
none is set yet?
I think this could be an option. We currently check
/var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid.
I think that the first should work for your use case, since you keep /var.
But we also check some commandline option, this seems useful for some
use cases.

Zbyszek
Tobias Hunger
2015-03-13 13:20:04 UTC
Permalink
Hi Zbyszek,

I would expect the machine-id to be written before mount units are
processed, so for that to work I would need to mount /var in the
initrd, wouldn't I?

Currently I am trying to just write the machine-id to /etc in the
initrd. This makes systemd loose the understanding that /etc is empty
though, which might have some side-effects that I am not yet
anticipating.

Isn't systemd started from inside the initrd once the new root has
been set up? Maybe I could set $container_uuid and feed the machine-id
to systemd that way? I am afraid that this will lead to some other
side-effects, because systemd might assume to be running inside a
container. Looks like I will have to do some testing over the
weekend:-)

Maybe I am lucky and /sys/class/dmi/id/product_uuid is set.

Best Regards,
Tobias

On Fri, Mar 13, 2015 at 1:16 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Post by Tobias Hunger
Post by Tobias Hunger
Post by Lennart Poettering
presets and machined ID are applied by PID 1, before it begins with
starting any units, hence *really* early on. Note though that actually
/etc/machine-id is used as flag for "is /etc empty". If the file
exists it is assumed that /etc is provisioned properly. If it is
missing PID 1 will generate the machiend id and apply presets.
An OS installer could put the machine-id into /usr just fine (and so
can I) and systemd could just get it from there if available before
generating a new one.
It would be nice if the machine-id did not change during to a factory
reset: It is used in the logs and changing it will basically make
historical log data much harder to analyze. IIRC networkd also uses it
to generate persistent MAC addresses for containers and such.
So far this seems to be the only critical piece of information that
can not get restored via tmpfiles.d.
Thinking about this a bit longer: /usr does not seem like a good idea.
The machine-id is supposed to be unique and usr-images are meant to be
reused.
Maybe provide a kernel command line option to force the machine-id if
none is set yet?
I think this could be an option. We currently check
/var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid.
I think that the first should work for your use case, since you keep /var.
But we also check some commandline option, this seems useful for some
use cases.
Zbyszek
Zbigniew Jędrzejewski-Szmek
2015-03-13 13:28:39 UTC
Permalink
Post by Tobias Hunger
Hi Zbyszek,
I would expect the machine-id to be written before mount units are
processed, so for that to work I would need to mount /var in the
initrd, wouldn't I?
(Without looking at the code again) I don't think so. machine-id-setup
is performed by PID1 itself, and I think it does it quite early.
Post by Tobias Hunger
Currently I am trying to just write the machine-id to /etc in the
initrd. This makes systemd loose the understanding that /etc is empty
though, which might have some side-effects that I am not yet
anticipating.
Yeah, that does not seem like the right approach.
Post by Tobias Hunger
Isn't systemd started from inside the initrd once the new root has
been set up? Maybe I could set $container_uuid and feed the machine-id
to systemd that way? I am afraid that this will lead to some other
side-effects, because systemd might assume to be running inside a
container. Looks like I will have to do some testing over the
weekend:-)
Maybe I am lucky and /sys/class/dmi/id/product_uuid is set.
Best Regards,
Tobias
Zbyszek
Tobias Hunger
2015-03-16 10:31:57 UTC
Permalink
Just a short update:

I managed to get my machine image to (kind of) boot in systemd-nspawn
this weekend. Kind-of as it tries to mount some drives that are
obviously not there in the container. But apart from that it seems to
boot fine:-)

On real hardware I am not so lucky: Once I get to
system-switch-root.service I get lots of output about missing nodes in
dev (/dev/ttyX mostly).

This might be due to me messing up the configuration, arch's
mkinitcpio being unprepared to handle a stateless system or some
problem in systemd. At this time I am not sure which.

I am rather positive that this will be really straight forward to
figure out once I can actually get a shell in the initrd, which
unfortunately seems harder than expected on Arch Linux (provided you
use systemd HOOK in /etc/mkinitcpio.conf, which is not the recommended
way of doing things):-/

Best Regards,
Tobias

PS: Any hints on systemd-in-initrd debugging in arch linux would be
appreciated at this point:-)
Post by Tobias Hunger
Hi Zbyszek,
I would expect the machine-id to be written before mount units are
processed, so for that to work I would need to mount /var in the
initrd, wouldn't I?
Currently I am trying to just write the machine-id to /etc in the
initrd. This makes systemd loose the understanding that /etc is empty
though, which might have some side-effects that I am not yet
anticipating.
Isn't systemd started from inside the initrd once the new root has
been set up? Maybe I could set $container_uuid and feed the machine-id
to systemd that way? I am afraid that this will lead to some other
side-effects, because systemd might assume to be running inside a
container. Looks like I will have to do some testing over the
weekend:-)
Maybe I am lucky and /sys/class/dmi/id/product_uuid is set.
Best Regards,
Tobias
On Fri, Mar 13, 2015 at 1:16 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Post by Tobias Hunger
Post by Tobias Hunger
Post by Lennart Poettering
presets and machined ID are applied by PID 1, before it begins with
starting any units, hence *really* early on. Note though that actually
/etc/machine-id is used as flag for "is /etc empty". If the file
exists it is assumed that /etc is provisioned properly. If it is
missing PID 1 will generate the machiend id and apply presets.
An OS installer could put the machine-id into /usr just fine (and so
can I) and systemd could just get it from there if available before
generating a new one.
It would be nice if the machine-id did not change during to a factory
reset: It is used in the logs and changing it will basically make
historical log data much harder to analyze. IIRC networkd also uses it
to generate persistent MAC addresses for containers and such.
So far this seems to be the only critical piece of information that
can not get restored via tmpfiles.d.
Thinking about this a bit longer: /usr does not seem like a good idea.
The machine-id is supposed to be unique and usr-images are meant to be
reused.
Maybe provide a kernel command line option to force the machine-id if
none is set yet?
I think this could be an option. We currently check
/var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid.
I think that the first should work for your use case, since you keep /var.
But we also check some commandline option, this seems useful for some
use cases.
Zbyszek
Lennart Poettering
2015-04-22 15:43:29 UTC
Permalink
Post by Tobias Hunger
I managed to get my machine image to (kind of) boot in systemd-nspawn
this weekend. Kind-of as it tries to mount some drives that are
obviously not there in the container. But apart from that it seems to
boot fine:-)
On real hardware I am not so lucky: Once I get to
system-switch-root.service I get lots of output about missing nodes in
dev (/dev/ttyX mostly).
Note that systemd only supports /dev mounted from devtmpfs, where the
nodes are created by the kernel (and not userspace), and hence cannot
really be missing. If the nodes are missing this is an indication that
/dev is configured in some other way...

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-04-22 15:41:50 UTC
Permalink
Post by Tobias Hunger
Hi Zbyszek,
I would expect the machine-id to be written before mount units are
processed, so for that to work I would need to mount /var in the
initrd, wouldn't I?
Yeah, /var/lib/dbus/machine-id isn't a general purpose solution, since
/var ca nbe mounted very late. (Also, as mentioned in other mail, it's
compat only, please don't use it.)
Post by Tobias Hunger
Currently I am trying to just write the machine-id to /etc in the
initrd. This makes systemd loose the understanding that /etc is empty
though, which might have some side-effects that I am not yet
anticipating.
Isn't systemd started from inside the initrd once the new root has
been set up? Maybe I could set $container_uuid and feed the machine-id
to systemd that way? I am afraid that this will lead to some other
side-effects, because systemd might assume to be running inside a
container. Looks like I will have to do some testing over the
weekend:-)
$container_uuid is only used in containers. If you set it in other
conditions, we don't care.
Post by Tobias Hunger
Maybe I am lucky and /sys/class/dmi/id/product_uuid is set.
That is only read on kvm, since on physical hardware it is more often
than not filled with rubbish, that is not useful as a real machine id.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-04-22 15:39:23 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Tobias Hunger
Post by Tobias Hunger
Post by Lennart Poettering
presets and machined ID are applied by PID 1, before it begins with
starting any units, hence *really* early on. Note though that actually
/etc/machine-id is used as flag for "is /etc empty". If the file
exists it is assumed that /etc is provisioned properly. If it is
missing PID 1 will generate the machiend id and apply presets.
An OS installer could put the machine-id into /usr just fine (and so
can I) and systemd could just get it from there if available before
generating a new one.
It would be nice if the machine-id did not change during to a factory
reset: It is used in the logs and changing it will basically make
historical log data much harder to analyze. IIRC networkd also uses it
to generate persistent MAC addresses for containers and such.
So far this seems to be the only critical piece of information that
can not get restored via tmpfiles.d.
Thinking about this a bit longer: /usr does not seem like a good idea.
The machine-id is supposed to be unique and usr-images are meant to be
reused.
Maybe provide a kernel command line option to force the machine-id if
none is set yet?
I think this could be an option. We currently check
/var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid.
I think that the first should work for your use case, since you keep /var.
But we also check some commandline option, this seems useful for some
use cases.
I think /var/lib/dbus/machine-id is nothing to use here. It purely
exists for compat with upgrades from classic dbus1 systems, where we
should avoid inventing a new machine id, if the dbus one is fine.

I'd be fine with adding a kernel switch to make this configurable, as
Zbigniew suggested.

Lennart
--
Lennart Poettering, Red Hat
Chris Murphy
2015-03-10 23:33:17 UTC
Permalink
Post by Tobias Hunger
Even if all filesystems are encrypted you could factory-reset random
computers you have access to, simply by editing the bootloader
configuration file usually found in the poorly protected EFI
partition!
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.

GRUB2 kinda does support this. The ESP grub.cfg can handle the
cryptodisk and luksopen to grant access to the encrypted volume; and
configfile command to load a new grub.cfg located on that volume. And
from there the boot is normal including reading kernel and initramfs
from the encrypted volume.
--
Chris Murphy
Tobias Hunger
2015-03-11 08:22:12 UTC
Permalink
Post by Chris Murphy
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.

Let's wait and see.

Best Regards,
Tobias
Chris Murphy
2015-03-11 17:32:05 UTC
Permalink
Post by Tobias Hunger
Post by Chris Murphy
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
Kay Sievers
2015-03-11 17:50:23 UTC
Permalink
Post by Chris Murphy
Post by Tobias Hunger
Post by Chris Murphy
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/
Post by Chris Murphy
And maybe done away with in favor of dynamic discovery and "hot" keys
for indicating common boot options.
The "all included" kernels are found at /boot/EFI/Linux/*.efi
Post by Chris Murphy
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.
We get that transparently from firmwares with "bios raid" support. We
will not care about any sort of conventional "software raid", because
the firmware itself will not handle it, and it makes nt much sense to
use over-complicated options in the later boot steps when it cannot
recover itself anyway.

For a single-system disk, the entire /boot, ESP content should rather be
seen as throw-way content which can be re-constructed from a running
system, from the content in /usr, at any given time. There is no
point in handling raid without native firmware support; manual
intervention is needed anyway on these systems if things go wrong, and
that step can just re-create the ESP content if needed.

Kay
Chris Murphy
2015-03-11 18:45:50 UTC
Permalink
\
Post by Kay Sievers
Post by Chris Murphy
The bootloader configuration files aren't signed. Maybe the should be.
https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/
That's definitely an improvement.
Post by Kay Sievers
Post by Chris Murphy
And maybe done away with in favor of dynamic discovery and "hot" keys
for indicating common boot options.
The "all included" kernels are found at /boot/EFI/Linux/*.efi
Yeah until the distros stop persistently mounting the ESP, I'm not a
fan at all of anything but the most minimalist approach to the ESP.
The FAT kernel maintainer says it's a bad idea, pretty much any crash
or panic while the ESP is mounted, even ro, can cause FAT corruption
and there's nothing to be done about it (well, fsck it at every boot
might help some, which also some distros don't ever do).
Post by Kay Sievers
Post by Chris Murphy
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.
We get that transparently from firmwares with "bios raid" support.
a.) such support lacks widespread availability
b.) Intel IMSM requires mdadm to manage it once the kernel is running,
and I'm not aware of any support for AMD's equivalent on Linux
c.) Intel IMSM is an all or nothing approach to whole devices, they
first go into a container, making both LVM and Btrfs raid impossible
on those devices.
Post by Kay Sievers
We
will not care about any sort of conventional "software raid", because
the firmware itself will not handle it, and it makes nt much sense to
use over-complicated options in the later boot steps when it cannot
recover itself anyway.
OK except this has worked just fine on BIOS systems for years and they
recover OK.

GRUB2's mdadm supports degraded 1,10, 4, 5, 6 booting. The identical
core.img is embedded in the MBR gap or BIOSBoot partition in each
drive. Each core.img looks to the same e.g. /boot/grub location on the
array, and can even find the kernel and initramfs on degraded raid6. I
don't care for that usecase especially, but it does work, completely
unattended. And at least a two disk raid1 degraded boot ought to work,
unattended.
Post by Kay Sievers
For a single-system disk, the entire /boot, ESP content should rather be
seen as throw-way content which can be re-constructed from a running
system, from the content in /usr, at any given time.
I agree with this. But it should be a very simple additional step to
apply this to all ESP's on the system to make sure all of them enable
the system to find a kernel and boot the system.
Post by Kay Sievers
There is no
point in handling raid without native firmware support; manual
intervention is needed anyway on these systems if things go wrong, and
that step can just re-create the ESP content if needed.
I don't agree with this. OS X supports this for 10+ years on EFI with
software raid, and no such thing as firmware raid. No manual
intervention is required in the degraded boot case. I'm not exactly
sure how Windows works, but they have bootable mirroring software raid
that doesn't depend on firmware raid.

It's not general purpose to have to depend on proprietary firmware
RAID to get UEFI resilient boot. This wasn't necessary on BIOS
systems, there's no good reason to require it now.
--
Chris Murphy
Kay Sievers
2015-03-11 19:46:45 UTC
Permalink
Post by Chris Murphy
Post by Kay Sievers
There is no
point in handling raid without native firmware support; manual
intervention is needed anyway on these systems if things go wrong, and
that step can just re-create the ESP content if needed.
I don't agree with this. OS X supports this for 10+ years on EFI with
software raid, and no such thing as firmware raid.
It is the Apple firmware and not OS X. The firmware supports all sorts
of Apple specific things like HFS+ and drivers for the WiFi hardware.
And that is exactly what I meant with native support. :)

Kay
Chris Murphy
2015-03-11 20:03:54 UTC
Permalink
Post by Kay Sievers
Post by Chris Murphy
Post by Kay Sievers
There is no
point in handling raid without native firmware support; manual
intervention is needed anyway on these systems if things go wrong, and
that step can just re-create the ESP content if needed.
I don't agree with this. OS X supports this for 10+ years on EFI with
software raid, and no such thing as firmware raid.
It is the Apple firmware and not OS X. The firmware supports all sorts
of Apple specific things like HFS+ and drivers for the WiFi hardware.
And that is exactly what I meant with native support. :)
Apple's raid support is not enabled by Apple firmware. That Apple's
firmware understands HFS+ is completely beside the point. They could
put their bootloader on the ESP, it's the bootloader that understands
Apple raid, finds and loads the kernel. The reason the firmware has
HFS+ support baked in is the HFS+ volume header contains a hint for
the active system, rather than depending on NVRAM.

Back on Linux though, any dependency on proprietary firmware raid,
means Btrfs raid cannot be used at all on those drives so I don't see
how this is a general purpose solution. BIOS permits a superior
solution.
--
Chris Murphy
Kay Sievers
2015-03-11 19:56:27 UTC
Permalink
Post by Chris Murphy
Post by Kay Sievers
The "all included" kernels are found at /boot/EFI/Linux/*.efi
Yeah until the distros stop persistently mounting the ESP, I'm not a
fan at all of anything but the most minimalist approach to the ESP.
Systemd by default mounts it with autofs, it will not be mounted until
it is accessed, which does not happen during normal operation. We
currently miss autofs timeout handling, which would umount /boot again
when it is no longer used. That would make stuff pretty robust, I
expect.

It's just that distros have their rather broken concept of putting it
into fstab, and even cascading mounts with splitting /boot and the
ESP.
Post by Chris Murphy
The FAT kernel maintainer says it's a bad idea, pretty much any crash
or panic while the ESP is mounted, even ro, can cause FAT corruption
and there's nothing to be done about it (well, fsck it at every boot
might help some, which also some distros don't ever do).
Right, the Linux FAT driver, or maybe just the way Linux handles the
writeback to disk, is absolutely fragile. Corrupted FAT file systems
are the norm and not the exception. We must mount it unconditionally,
it will just break after a while.

Kay
Chris Murphy
2015-03-11 20:41:43 UTC
Permalink
Post by Kay Sievers
Systemd by default mounts it with autofs, it will not be mounted until
it is accessed, which does not happen during normal operation. We
currently miss autofs timeout handling, which would umount /boot again
when it is no longer used. That would make stuff pretty robust, I
expect.
It's just that distros have their rather broken concept of putting it
into fstab, and even cascading mounts with splitting /boot and the
ESP.
That's an improvement, sure.

But the very idea of ESPs that need any post-install modification in
the first place is what introduces this fragility in the first place.
Windows never makes ESP modifications post-install, and OS X only does
it to stage firmware update payloads.

The paradigm that wants to place things often being changed: kernel,
initramfs, bootloader scripts, is what causes the need to sync
multiple ESPs in the first place. And proprietary raid is not a
general purpose way of getting around this.

A more general purpose solution for UEFI would be EFI drivers for
various filesystems including md, LVM, and Btrfs, so that there's
quasi-native firmware support for them. And then there's no reason to
ever touch the ESP again nor depend on firmware raid to effectively
replicate the kernel and initramfs.
Post by Kay Sievers
Post by Chris Murphy
The FAT kernel maintainer says it's a bad idea, pretty much any crash
or panic while the ESP is mounted, even ro, can cause FAT corruption
and there's nothing to be done about it (well, fsck it at every boot
might help some, which also some distros don't ever do).
Right, the Linux FAT driver, or maybe just the way Linux handles the
writeback to disk, is absolutely fragile. Corrupted FAT file systems
are the norm and not the exception. We must mount it unconditionally,
it will just break after a while.
Apple and Microsoft essentially trust it zero, and don't persistently
mount it. So I don't know the cause but I filed a bug a while ago and
it's basically expected behavior.
https://bugzilla.kernel.org/show_bug.cgi?id=92721
--
Chris Murphy
Chris Murphy
2015-03-11 20:52:01 UTC
Permalink
Post by Chris Murphy
A more general purpose solution for UEFI would be EFI drivers for
various filesystems including md, LVM, and Btrfs, so that there's
quasi-native firmware support for them.
Interesting. ext4, ReiserFS, Btrfs, NTFS, and HFS+ UEFI drivers.
http://www.rodsbooks.com/refind/drivers.html

Apparently this makes GRUB fs modules into stand alone EFI drivers.
http://efi.akeo.ie/
--
Chris Murphy
Andrei Borzenkov
2015-03-12 03:39:24 UTC
Permalink
В Wed, 11 Mar 2015 14:41:43 -0600
Post by Chris Murphy
Post by Kay Sievers
Systemd by default mounts it with autofs, it will not be mounted until
it is accessed, which does not happen during normal operation. We
currently miss autofs timeout handling, which would umount /boot again
when it is no longer used. That would make stuff pretty robust, I
expect.
It's just that distros have their rather broken concept of putting it
into fstab, and even cascading mounts with splitting /boot and the
ESP.
That's an improvement, sure.
But the very idea of ESPs that need any post-install modification in
the first place is what introduces this fragility in the first place.
Windows never makes ESP modifications post-install,
Windows bootloader configuration is stored on ESP; of course it is not
changed often. Also Windows still needs to update bootloader every
now and then. This is actually quite similar to secure boot with grub2
used by Linux today where only pointer to /boot need to be set. As
neither binary nor grub.cfg snippet normally change we probably could
skip even that after initial installation.
Chris Murphy
2015-03-12 06:02:28 UTC
Permalink
Post by Andrei Borzenkov
Windows bootloader configuration is stored on ESP; of course it is not
changed often. Also Windows still needs to update bootloader every
now and then.
I'm not seeing a BCD on the ESP, that's usually on NTFS historically
anyway. I see bootmgfw.efi, and bootmgr.efi.
Post by Andrei Borzenkov
This is actually quite similar to secure boot with grub2
used by Linux today where only pointer to /boot need to be set.
Right, with a grub.cfg using configfile on the ESP to point to a
"real" grub.cfg, or BLS snippets, on /boot. Or even better would be
dynamic discovery similar to gummiboot, rEFInd, and the built-in boot
manager in Apple's firmware (talk about something that's very rarely
updated).
Post by Andrei Borzenkov
As
neither binary nor grub.cfg snippet normally change we probably could
skip even that after initial installation.
Yes I'd like to see GRUB on the ESP be totally generic, except for an
installer created grub.cfg that merely forwards to the real one on
/boot. Then it's on a more reliable fs, it can be mirrored, and that
one is always updated when there are kernel upgrades, rather than the
one on the ESP. openSUSE does this already, maybe also Ubuntu. Fedora
doesn't, it's main grub.cfg is on the ESP and that's the one always
modified whenever kernels are installed, and since Fedora gets lots of
kernel updates, this file is always being modified. I've tried to
encourage a different strategy!
https://bugzilla.redhat.com/show_bug.cgi?id=1048999
--
Chris Murphy
Lennart Poettering
2015-04-22 15:52:57 UTC
Permalink
Post by Kay Sievers
Post by Chris Murphy
Post by Kay Sievers
The "all included" kernels are found at /boot/EFI/Linux/*.efi
Yeah until the distros stop persistently mounting the ESP, I'm not a
fan at all of anything but the most minimalist approach to the ESP.
Systemd by default mounts it with autofs, it will not be mounted until
it is accessed, which does not happen during normal operation. We
currently miss autofs timeout handling, which would umount /boot again
when it is no longer used. That would make stuff pretty robust, I
expect.
Quick update on this: autofs expiry is now implemented and enabled for
the ESP mount systemd does by default.

This should shorten the time-frame of corruptions of the ESP quite a
bit.

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2015-03-12 03:57:36 UTC
Permalink
В Wed, 11 Mar 2015 18:50:23 +0100
Post by Kay Sievers
Post by Chris Murphy
Post by Tobias Hunger
Post by Chris Murphy
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.
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.
David Herrmann
2015-03-12 10:30:43 UTC
Permalink
Hi
Post by Andrei Borzenkov
В Wed, 11 Mar 2015 18:50:23 +0100
Post by Kay Sievers
Post by Chris Murphy
Post by Tobias Hunger
Post by Chris Murphy
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.
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
Kay Sievers
2015-03-12 10:39:46 UTC
Permalink
Post by David Herrmann
Post by Andrei Borzenkov
В Wed, 11 Mar 2015 18:50:23 +0100
Post by Kay Sievers
Post by Chris Murphy
Post by Tobias Hunger
Post by Chris Murphy
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.
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.
http://people.freedesktop.org/~kay/efistub.txt

Kay
Andrei Borzenkov
2015-03-12 13:06:57 UTC
Permalink
Post by David Herrmann
Hi
Post by Andrei Borzenkov
В Wed, 11 Mar 2015 18:50:23 +0100
Post by Kay Sievers
Post by Chris Murphy
Post by Tobias Hunger
Post by Chris Murphy
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.
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?
Post by David Herrmann
Thanks
David
David Herrmann
2015-03-12 13:24:10 UTC
Permalink
Hi
Post by Andrei Borzenkov
Post by David Herrmann
Post by Andrei Borzenkov
Post by Kay Sievers
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)

Thanks
David
Andrei Borzenkov
2015-03-12 13:41:57 UTC
Permalink
Post by David Herrmann
Hi
Post by Andrei Borzenkov
Post by David Herrmann
Post by Andrei Borzenkov
Post by Kay Sievers
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?
David Herrmann
2015-03-12 13:44:28 UTC
Permalink
Hi
Post by Andrei Borzenkov
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.
The signed EFI binary is distributed by your
distribution/vendor/key-owner. The machine-owner is responsible of
putting the key of your vendor into the firmware.

Thanks
David
Tom Gundersen
2015-03-12 14:11:31 UTC
Permalink
Post by Andrei Borzenkov
Post by David Herrmann
Hi
Post by Andrei Borzenkov
Post by David Herrmann
Post by Andrei Borzenkov
Post by Kay Sievers
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).

Cheers,

Tom
Continue reading on narkive:
Loading...