Re: [OE-core] [PATCH v3 01/11] systemd: enable efi support by default

[Adrian Freihofer <adrian.freihofer@gmail.com>]

On Wed, 2025-04-16 at 09:08 +0300, Mikko Rapeli wrote:
> Hi,
> 
> On Tue, Apr 15, 2025 at 04:20:50PM +0000, Peter Kjellerstedt wrote:
> > > -----Original Message-----
> > > From:
> > > openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org
> > > > On Behalf Of Mikko Rapeli via lists.openembedded.org
> > > Sent: den 15 april 2025 11:52
> > > To: Adrian Freihofer <adrian.freihofer@gmail.com>
> > > Cc: openembedded-core@lists.openembedded.org;
> > > mike.looijmans@topic.nl
> > > Subject: Re: [OE-core] [PATCH v3 01/11] systemd: enable efi
> > > support by default
> > > 
> > > Hi,
> > > 
> > > On Mon, Apr 14, 2025 at 06:28:13PM +0200, Adrian Freihofer wrote:
> > > > Hi Mikko
> > > > 
> > > > Would it be possible to provide some numbers on the impact on
> > > > the size of
> > > > the binaries and the additional dependencies that could be
> > > > added to the
> > > > image with or without efi enabled?
> > > > I think the patch would be a very good compromise if the impact
> > > > is
> > > > negligible, but otherwise the question is probably still valid.
> > 
> > I have probably missed something in this very long thread, but what
> > is the 
> > reason to force EFI support on us rather than relying on the efi
> > distro 
> > feature? We do not use EFI in any of our products and thus do not
> > have it 
> > set in DISTRO_FEATURES. If it is suddenly expected that EFI support
> > should 
> > be enabled all over the place it just means I will have to go
> > hunting for 
> > it to turn it off rather than just relying on the existing distro
> > feature.
> 
> Is it ok for Richard to enable "efi" in poky/poky-altcfg
> DISTRO_FEATURES
> by default?
> 
> It is already enabled in MACHINE_FEATURES for oe-core machines I care
> about.
> 
> > > 
> > > The impact is small:
> > > 
> > >  * python3-pyelftools-native is added to build dependencies
> > > 
> > >  * At runtime the efivars partition is now automatically mounted
> > > read-only by
> > >    systemd to /sys/firmware/efi/efivars and can be used to query
> > > various firmware
> > >    and EFI bootloader (grub, systemd-boot) details
> > > 
> > >  * Since "efi" is now default, other layers can stop enabling it:
> > > 
> > >   
> > > https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-core/systemd/systemd-efi.inc
> > >   
> > > https://git.yoctoproject.org/meta-security/tree/meta-tpm/recipes-core/systemd/systemd_%25.bbappend#n5
> > >   
> > > https://github.com/Wind-River/meta-secure-core/blob/master/meta-efi-secure-boot/recipes-core/systemd/systemd-efi-secure-boot.inc
> > 
> > But isn't the problem here rather that these layers want to force
> > EFI 
> > support instead of using, e.g., REQUIRED_DISTRO_FEATURES = "efi"?
> 
> These layers want to enable EFI support but don't want to change the
> poky/poky-altcfg
> distro settings.
> 
> In machine features "efi" is already enabled but it was rejeted here
> to use
> MACHINE_FEATURES in systemd.
> 
> So full loop in the discussion...?
> 
> Enabling systemd "efi" support by default is a tiny thing which would
> get lost
> all the other changes and IMO would not impact anyone significantly
> at runtime or at build time. Those who optimize systemd for e.g. non-
> EFI
> systems should be setting PACKAGECONFIG fully to their liking.

I understand why ARM is pushing for EFI by default.
- For servers, laptops, makers and other use cases, it is important to
provide a stable ABI between the bootloader and the rest of the system.
However, so far this is often just a “nice to have” requirement for
truly industrial-grade, robust, Yocto-based embedded products.
- In the future, features like secure boot or remote attestation will
become much more important for many products. I think EFI (in
combination with a TPM) can be of great help in this area. So it seems
to be less a question of whether EFI will find its way into more
OE/Yocto-based products, but much more a question of when it will find
its way into more OE/Yocto-based products. Maybe it should become the
default as soon as possible.

> 
> > > 
> > >  * /usr/lib/systemd/libsystemd-shared-257.so size increases 32
> > > bytes from
> > >    4012152 to 4012184 bytes, 0.0008%

That looks like a great compromise for EFI built-in by default.

> > > 
> > >  * systemd package size increase from 9857529 to 10226508, 3.7%,
> > > with
> > >    added files:
> > > 
> > > +drwxr-xr-x root       root             4096
> > > ./usr/lib/systemd/boot
> > > +drwxr-xr-x root       root             4096
> > > ./usr/lib/systemd/boot/efi
> > > +-rw-r--r-- root       root             6144
> > > ./usr/lib/systemd/boot/efi/addonaa64.efi.stub
> > > +-rw-r--r-- root       root           101376
> > > ./usr/lib/systemd/boot/efi/linuxaa64.efi.stub
> > > +-rw-r--r-- root       root           120832
> > > ./usr/lib/systemd/boot/efi/systemd-bootaa64.efi
> > > +-rwxr-xr-x -          -               67656
> > > ./usr/lib/systemd/systemd-bless-boot
> > > +-rwxr-xr-x -          -               67456
> > > ./usr/lib/systemd/system-generators/systemd-bless-boot-generator
> > > +lrwxrwxrwx -          -                  25
> > > ./usr/lib/systemd/system/sockets.target.wants/systemd-
> > > bootctl.socket -> ../systemd-bootctl.socket
> > > +lrwxrwxrwx -          -                  35
> > > ./usr/lib/systemd/system/sysinit.target.wants/systemd-boot-
> > > random-seed.service -> ../systemd-boot-random-seed.service
> > > +lrwxrwxrwx -          -                  34
> > > ./usr/lib/systemd/system/sysinit.target.wants/systemd-hibernate-
> > > clear.service -> ../systemd-hibernate-clear.service
> > > +-rw-r--r-- -          -                 690
> > > ./usr/lib/systemd/system/systemd-bless-boot.service
> > > +-rw-r--r-- -          -                 532
> > > ./usr/lib/systemd/system/systemd-bootctl@.service
> > > +-rw-r--r-- -          -                 596
> > > ./usr/lib/systemd/system/systemd-bootctl.socket
> > > +-rw-r--r-- -          -                1029
> > > ./usr/lib/systemd/system/systemd-boot-random-seed.service
> > > +-rw-r--r-- -          -                 733
> > > ./usr/lib/systemd/system/systemd-boot-update.service
> > > +-rw-r--r-- -          -                 782
> > > ./usr/lib/systemd/system/systemd-hibernate-clear.service
> > > +-rw-r--r-- -          -                 779
> > > ./usr/lib/tmpfiles.d/20-systemd-stub.conf
> > > 
> > >   This shows a bug in the config between systemd and systemd-
> > > boot, the EFI binaries are
> > >   provided by both. Sadly systemd-boot doesn't work so well and
> > > doesn't install all
> > >   the services etc which systemd does with "efi" and bootloader
> > > enabled. Not sure
> > >   if the overlap should be fixed or ignored. Using meson to
> > > install systemd-boot
> > >   binaries does fix deployment of the EFI binaries but does not
> > > install the
> > >   random-seed etc services. With this workaround to avoid the EFI
> > > file duplication
> > >   in systemd recipe:

It looks to me like more cleanup is needed here before EFI can be
enabled by default. It should be possible to get only the 0.0008% extra
size of the systemd package into an image if systemd is compiled with
EFI support, but the systemd-boot package is not installed into the
image.

There should also be some kind of confirmation from the systemd
community that such a package split is supported by design and will
remain so in the future. At least the Fedora package distribution looks
like this:
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_560
.

I'm not sure if some tests are needed to check that compiling with efi
but using it without the systemd-boot package actually works. But at
the moment it seems a bit too much like taking risks for non-EFI users.

Thank you for sharing these numbers!
Adrian


> > > 
> > > --- a/meta/recipes-core/systemd/systemd_257.5.bb
> > > +++ b/meta/recipes-core/systemd/systemd_257.5.bb
> > > @@ -149,7 +149,7 @@ PACKAGECONFIG[default-compression-lz4] = "-
> > > Dlz4=true -Ddefault-compression=lz4,,
> > >  PACKAGECONFIG[default-compression-xz] = "-Dxz=true -Ddefault-
> > > compression=xz,,xz"
> > >  PACKAGECONFIG[default-compression-zstd] = "-Dzstd=true -
> > > Ddefault-compression=zstd,,zstd"
> > >  PACKAGECONFIG[dbus] = "-Ddbus=enabled,-Ddbus=disabled,dbus"
> > > -PACKAGECONFIG[efi] = "-Defi=true -Dbootloader=enabled,-
> > > Defi=false -Dbootloader=disabled,python3-pyelftools-native"
> > > +PACKAGECONFIG[efi] = "-Defi=true -Dbootloader=disabled,-
> > > Defi=false -Dbootloader=disabled,python3-pyelftools-native
> > > systemd-boot"
> > > 
> > >   size without "efi" is 9857529 bytes and with "efi" 9859196, or
> > > size increase
> > >   of 0.016% which is tiny. To stay closer to systemd upstream, I
> > > don't think
> > >   removing the duplication is worth the effort for now. systemd-
> > > boot
> > >   recipe could maybe be replaced by systemd recipe and a systemd-
> > > boot binary
> > >   package. Otherwise the configurations don't match. FWIW, it
> > > tried following
> > >   changes to systemd-boot:
> > > 
> > > --- a/meta/recipes-core/systemd/systemd-boot_257.5.bb
> > > +++ b/meta/recipes-core/systemd/systemd-boot_257.5.bb
> > > @@ -24,6 +24,7 @@ EOF
> > >  MESON_CROSS_FILE:append = " --cross-file ${WORKDIR}/meson-
> > > ${PN}.cross"
> > > 
> > >  MESON_TARGET = "systemd-boot"
> > > +MESON_INSTALL_TAGS = "systemd-boot"
> > > 
> > >  EXTRA_OEMESON += "-Defi=true \
> > >                    -Dbootloader=true \
> > > @@ -43,7 +44,7 @@ python __anonymous () {
> > >      d.setVar("SYSTEMD_BOOT_IMAGE_PREFIX", prefix)
> > >  }
> > > 
> > > -FILES:${PN} = "${EFI_FILES_PATH}/${SYSTEMD_BOOT_IMAGE}"
> > > +FILES:${PN} = "${EFI_FILES_PATH}/${SYSTEMD_BOOT_IMAGE}
> > > ${libdir}"
> > > 
> > >  RDEPENDS:${PN} += "virtual-systemd-bootconf"
> > > 
> > > @@ -53,6 +54,7 @@ COMPATIBLE_HOST =
> > > "(aarch64.*|arm.*|x86_64.*|i.86.*|riscv.*)-linux"
> > >  COMPATIBLE_HOST:x86-x32 = "null"
> > > 
> > >  do_install() {
> > > +       meson_do_install
> > >         install -d ${D}${EFI_FILES_PATH}
> > >         install ${B}/src/boot/systemd-boot*.efi
> > > ${D}${EFI_FILES_PATH}/${SYSTEMD_BOOT_IMAGE}
> > >  }
> > > 
> > > Cheers,
> > > 
> > > -Mikko
> > 
> > //Peter
> >