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

Ilias Apalodimas
2025-04-11T11:46:30Z

Hi Adrian

On Thu, 10 Apr 2025 at 23:53, Adrian Freihofer
<adrian.freihofer@gmail.com> wrote:
>
> On Thu, 2025-04-10 at 15:12 +0300, Ilias Apalodimas wrote:
> > Apologies for the noise, I forgot to add Adrian in CC
> >
> > On Thu, 10 Apr 2025 at 14:45, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Adrian
> > >
> > > On Thu, 10 Apr 2025 at 14:21, Adrian Freihofer
> > > <mikko.rapeli@linaro.org> wrote:
> > > >
> > > > Hi Mikko
> > > >
> > > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > > lists.openembedded.org wrote:
> > > > > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > > > > and in u-boot. Boot without "efi" in systemd works with
> > > > > EFI protocols but for example efivars is not mounted at
> > > > > all so various checks fail in userspace. Fix these by
> > > > > enabling "efi" support by default to avoid making
> > > > > it machine specific. Fixes efivars mount to
> > > > > /sys/firmware/efi/efivars etc.
> > > >
> > > > My point is that many OE/Yocto-based embedded products rely on a
> > > > fully
> > > > redundant and power fail-safe firmware update and boot
> > > > implementation.
> > > > So far I have not understood how this could be implemented in a
> > > > similarly robust way based on EFI as we have now without EFI-
> > > > based
> > > > boot-up.
> > >
> > > As far as the firmware updates are concerned there's [0], which is
> > > also implemented in U-Boot.
> > > But even in that case, I am not sure I understand your concerns.
> > > What
> > > prevents you from having the existing mechanisms for firmware
> > > updates
> > > on a system that boots with EFI?
>
> Many thanks for the link.

yw

> Yes, that basically describes how it should
> be. But is there such a thing in reality?

Yes it actually works for some boards in U-Boot and people are
shipping it. I am also discussing with the fwupd maintainers on how to
make it seamless in the future.

The Socionext Synquacer and some ST (stmp32mp1) are the ones I
remember. We definitely want to add more boards.

> The discussion here doesn't
> really convince me that EFI is already the proven easy way to build
> robust and maintainable embedded systems.

Again, I'll limit the discussion in U-Boot -- if there are other EFI
implementations you are worried about, feel free to add them.
UEFI has a weird learning curve, I understand that but it standardizes
a few things that people are struggling with and that's why distros
use it.
I don't know if that's useful for vertical distros -- but the ability
to boot the same OS across many different devices is appealing to some
vendors. It also tries to standardize security and most notably Secure
Boot and measured boot which is a usual headache. There's still a
vendor specific bit in there on how to setup your chain of trust, but
once you reach BL33( the efi loader) everything looks identical.
U-Boot nowadays is pretty complete. You can literally install a distro
using its installer either via putting the installer on a disk or
doing it over HTTP.
There are some kernel module requirements for the latter, but AFAIK
debian and the latest fedora42 already support the modules (notably
OF_PMEM).

> I understand why many people
> are working towards EFI. But I still see great advantages in simpler
> and available (in the sense of power-fail, robust) technologies for
> many use cases today.

Fair enough. However, what I am trying to say here is with or without
EFI i am not aware of any limitations. In fact most of the arch
kernels build with EFI support enabled by default.
IOW, no one *forces* you to use capsule updates to update your
firmware or use EFI to boot your system.

>
> Anyway, my intention is not to start a controversial discussion about
> EFI or SystemReady. My intention is to ensure that building systems
> without disadvantages caused by the "EFI by default strategy" remains
> possible and ideally also tested. As long as that is the case, I fully
> agree with the patch.

Understood and as I said, I don't think it will break anything -- and
if it does, we should just fix it because in principle it shouldn't.

>
> > >
> > > > I would therefore like to see the EFI implementation remain
> > > > opt-in until it covers at least the most important use cases for
> > > > robust
> > > > embedded systems. What I primarily miss with EFI is a reference
> > > > implementation for an A/B update system without having to rely on
> > > > a FAT
> > > > partition without journaling. Please correct me if I'm missing
> > > > something!
> > >
> > > Where does the FAT partition requirement come from?
> > >
> > > >
> > > > Would it make sense to declare poky as an EFI ready reference
> > > > distribution by enabling the efi DISTRO_FEATURE there, rather
> > > > than
> > > > starting with making recipes enabling efi unconditionally?
> > > >
> > > > Could something like this in poky.conf work?
> > > > DISTRO_FEATURES:append:aarch64 = " efi"
> > > > DISTRO_FEATURES:append:riscv64 = " efi"
> > > > DISTRO_FEATURES:append:x86-64 = " efi"
>
> I was thinking about making this ARCH specific because:
> - Defaulting to the most typical and use cases
> - Keep a test matrix on the AB which builds systemd without efi
> - ARCH specific is not an issue like MACHINE specific would be
> - Having this policy in the distro seams more logical to me than in a
> generic package.
>
> But as I said, if the disadvantages of building with efi are negligible
> for users without EFI use cases, then even better.

Agreed.

Thanks
/Ilias
>
> Thank you and regards,
> Adrian
>
> > >
> > > [0]
> > > https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md
> > >
> > > Thanks
> > > /Ilias
> > > >
> > > > Thank you and regards,
> > > > Adrian
> > > >
> > > > >
> > > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > > ---
> > > > > meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
> > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > index 64fb8fe69a..06e5621398 100644
> > > > > --- a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
> > > > > "
> > > > >
> > > > > PACKAGECONFIG ??= " \
> > > > > - ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > > > efi
> > > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > > > + ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > > > ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
> > > > > 'coredump elfutils', '', d)} \
> > > > > ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill',
> > > > > '',
> > > > > d)} \
> > > > > ${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> > > > > 'xkbcommon', '',
> > > > > d)} \
> > > > > ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit',
> > > > > 'sysvinit',
> > > > > 'link-udev-shared', d)} \
> > > > > backlight \
> > > > > binfmt \
> > > > > + efi \
> > > > > gshadow \
> > > > > hibernate \
> > > > > hostnamed \
> > > > >
> > > > >
> > > > >
> > > >
>