Trying to use meta-efibootguard

[Guthrie Hamish]

Hello,

I am wanting to evaluate efibootguard for use in some x86 platforms we are running. We have existing solutions for efi booting but the implementation was done some time ago and they need to be refreshed. I have been trying to use the meta-efibootguard layer and I am just wondering if it is still being maintained - the last commit was 13-6-2024 and it is on efibootguard 0.17.

Thanks

Hamish

[Jan Kiszka]

I guess it's time discuss this openly:

Michael already expressed to me a while ago that he cannot work on it
very often. Problem for me is that I do not have a target for this layer
anymore, plus there is no testing setup for accepting PRs without own,
then likely manual testing effort.

Who is using this layer? Who would be able to help out, with providing
updates from time to time and with making them better testable (some
pipeline that builds and runs a qemu image at least)?

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Guthrie Hamish]

Hello Jan,

>Michael already expressed to me a while ago that he cannot work on it

>very often. Problem for me is that I do not have a target for this layer
>anymore, plus there is no testing setup for accepting PRs without own,
>then likely manual testing effort.

Thanks for your open answer, and I must say that I suspected this scenario.

>Who is using this layer? Who would be able to help out, with providing
>updates from time to time and with making them better testable (some
>pipeline that builds and runs a qemu image at least)?

I am seriously considering using this layer for a few products we have

which are x86-based and built with Yocto. I would be happy to provide

patches to bring it up to date as of now. If we do adopt efibootguard for

our products, I would also be happy to provide ongoing patches and 
developing a pipeline to build and run a qemu image would not be out
of the question, but it is early days yet.

I have made a lot of progress with efibootguard in our Yocto environment
over the last few days and I have a good feeling about it and the principles
involved. We have  diverse embedded environments, comprising 2
ARM-based platforms,  for which we use Yocto and swupdate, but not sure
about efibootguard, however, we have 3 deeply embedded x86 platforms
for which we use Yocto and swupdate, and it is for these I am currently
most interested in as the existing platform is not completely current and I
would like to use efibootguard for this. In addition we have a few
requirements where the CIP would be very attractive and we are seriously
considering adopting CIP for these - but this requires further discussion.

Hamish

[Jan Kiszka]

On 25.03.25 18:51, 'Guthrie Hamish' via EFI Boot Guard wrote:
> Hello Jan,
>
>>Michael already expressed to me a while ago that he cannot work on it
>>very often. Problem for me is that I do not have a target for this layer
>>anymore, plus there is no testing setup for accepting PRs without own,
>>then likely manual testing effort.
>
> Thanks for your open answer, and I must say that I suspected this scenario.
>
>>Who is using this layer? Who would be able to help out, with providing
>>updates from time to time and with making them better testable (some
>>pipeline that builds and runs a qemu image at least)?
>
> I am seriously considering using this layer for a few products we have
> which are x86-based and built with Yocto. I would be happy to provide
> patches to bring it up to date as of now. If we do adopt efibootguard for
> our products, I would also be happy to provide ongoing patches and 
> developing a pipeline to build and run a qemu image would not be out
> of the question, but it is early days yet.
>

Thanks for this offer!

> I have made a lot of progress with efibootguard in our Yocto environment
> over the last few days and I have a good feeling about it and the principles
> involved. We have  diverse embedded environments, comprising 2
> ARM-based platforms,  for which we use Yocto and swupdate, but not sure
> about efibootguard, however, we have 3 deeply embedded x86 platforms
> for which we use Yocto and swupdate, and it is for these I am currently
> most interested in as the existing platform is not completely current and I
> would like to use efibootguard for this. In addition we have a few
> requirements where the CIP would be very attractive and we are seriously
> considering adopting CIP for these - but this requires further discussion.
>

Sure. The approach we developed in CIP is conceptually not bound to the
isar-based integration there. However, this layer here does not yet
support unified kernel image generation like we do over there. And one
of the reason to have EBG providing the UKI is non-x86: there is too
often the need to update the DTB in lock-step with the kernel (sigh).

[Guthrie Hamish]

>Sure. The approach we developed in CIP is conceptually not bound to the
>isar-based integration there. However, this layer here does not yet
>support unified kernel image generation like we do over there. And one
>of the reason to have EBG providing the UKI is non-x86: there is too
>often the need to update the DTB in lock-step with the kernel (sigh).

It may sound crazy, but I have introduced DT into our x86 kernels because
we use DT for defining blocks in our FPGA's which are used in both ARM and

x86 platforms, so I have UKI building using the layer, but I just wrapped the 

bg_gen_unified_kernel in our image creation recipe, but I would obviously prefer
to have it as part of the efibootguard wic plugin.

I would be very interested in hearing how you use efi in the boot process of
Arm platforms. Is there documentation for this you could point me to perhaps?

We are also wanting to build for Nvidia Tegra platforms (and that would be using
ISAR) - would know per chance if there is anyone else using ISAR for these
platforms?

I will be out of office the whole week next week, but I could submit some initial
patches when I return from holidays.

Hamish

[Jan Kiszka]

On 27.03.25 19:45, 'Guthrie Hamish' via EFI Boot Guard wrote:
>
>>Sure. The approach we developed in CIP is conceptually not bound to the
>>isar-based integration there. However, this layer here does not yet
>>support unified kernel image generation like we do over there. And one
>>of the reason to have EBG providing the UKI is non-x86: there is too
>>often the need to update the DTB in lock-step with the kernel (sigh).
>
> It may sound crazy, but I have introduced DT into our x86 kernels because
> we use DT for defining blocks in our FPGA's which are used in both ARM and
> x86 platforms, so I have UKI building using the layer, but I just
> wrapped the 
> bg_gen_unified_kernel in our image creation recipe, but I would
> obviously prefer
> to have it as part of the efibootguard wic plugin.
>
> I would be very interested in hearing how you use efi in the boot process of
> Arm platforms. Is there documentation for this you could point me to
> perhaps?

Have a look here:
https://elinux.org/images/4/42/ELCE2022-UEFISecureBootOTAUpdatesOnARM.pdf

Or study this isar layer for a (public) example:
https://github.com/siemens/meta-iot2050

>
> We are also wanting to build for Nvidia Tegra platforms (and that would
> be using
> ISAR) - would know per chance if there is anyone else using ISAR for these
> platforms?
>

Our SIMATIC IPC BX-35A (Orin-based) was enabled also with Debian, using
isar to describe images for it. Unfortunately, the BSP layer is nothing I can
share.

> I will be out of office the whole week next week, but I could submit
> some initial
> patches when I return from holidays.

No worries, same here.

Thanks,