[systemd-devel] [PATCH] Add syste-firmware-efi-efivars.mount for support automount EFI variable filesystem

[Kay Sievers]

On Wed, Oct 24, 2012 at 3:09 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Wed, Oct 24, 2012 at 03:00:14PM +0200, Kay Sievers wrote:
>> On Wed, Oct 24, 2012 at 2:23 PM, Zbigniew Jędrzejewski-Szmek
>> <zbyszek at in.waw.pl> wrote:
>> > On Wed, Oct 24, 2012 at 02:17:39PM +0200, Kay Sievers wrote:
>> >> On Wed, Oct 24, 2012 at 2:12 PM, Zbigniew Jędrzejewski-Szmek
>> >> <zbyszek at in.waw.pl> wrote:
>> >> > On Wed, Oct 24, 2012 at 06:42:02PM +0800, Lee, Chun-Yi wrote:
>> >> >> Add units/sys-firmware-efi-efivars.mount rule for support automount EFI variable filesystem
>> >> >
>> >> > in systemd parlance, automount means autofs mount, but to have that, a
>> >> > second .automount unit is needed.  Please have a look at
>> >> > http://cgit.freedesktop.org/systemd/systemd/tree/units/proc-sys-fs-binfmt_misc.automount
>> >> > vs
>> >> > http://cgit.freedesktop.org/systemd/systemd/tree/units/proc-sys-fs-binfmt_misc.mount .
>> >> > Now the question is whether the loading of the fs is slow enough to
>> >> > matter, ie. if it is actually beneficial to use automount instead of
>> >> > mounting directly.  Since the fs can be compiled as a module, than it
>> >> > probably is.
>> >> >
>> >> > Also, would be nice to add a Documentation= line like in
>> >> > proc-sys-fs-binfmt_misc.automount.
>> >>
>> >> It might all not be worth it, and we might just add it to the
>> >> "unconditionally mounted" list in the compiled-in code (marked with
>> >> allowed-to-fail). It seems like the better option than having a mount
>> >> unit, and a module-load force option.
>> > Probably should be measured by someone with UEFI.
>>
>> I'll check that when it's merged; in 3.8, I guess.
>>
>> > This will likely be
>> > a very rarely used fs
>>
>> We will likely end up using it ourselves from PID1 to extract boot
>> loader performance data, just like we do the initrd and other timing
>> data there. So an automount might not give us any real advantage in
>> the end.
> OK.
>
>> > so if the loading time is actually measureable,
>> > than automount probably makes sense.
>>
>> On EFI systems it will not really be measurable, I guess. The mount is
>> almost free, because the superblock is in the kernel anyway, very much
>> like like proc, sysfs, devtmpfs.
>>
>> For non-EFI systems, it might cause a "useless" kernel-initiated
>> modprobe, which we probably want to avoid by some condition.
>>
>> >> The current mount unit would never trigger for modules, because the
>> >> path will not exist. An internal API mount will cause a trransparent
>> >> kernel-forked modprobe with the mount() syscall.
>> > Yeah, the ConditionPathExists would have to be dropped.
>>
>> Right, but maybe we can key-off some other condition, which indicates
>> an EFI bootup, so we can avoid trying to mount things on systems where
>> it can't be there.
>>
>> Looking at if from a distance:
>> I guess the kernel should just start mounting its "crap" on its own,
>> instead of relying on userspace to know anything about this
>> ever-changing stuff. This filesytem is just a directory in /sys,
>> nothing else for userspace to know about it.
> Actually, in a container, it might make sense to not mount
> /sys/firmware/efi/efivars, since it opens an avenue to modify kernel
> state.

/sys (and all below) should be read-only inside a container anyway, so
it would only be readable, which might be bad enough, but not that
much different from the rest of /sys.

"Make sure to pre-mount /sys, and /proc, /sys/fs/selinux before
invoking systemd, and mount /proc/sys and the entirety of /sys and
/sys/fs/selinux read-only in order to avoid that the container can
alter the host kernel's configuration settings."
  http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface

Also, in a container we mount 'sysfs' explicitly, not with a
bind-mount from the host, so this would not be inherited anyway, I
guess.

Kay