All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>,
	openembedded-core@lists.openembedded.org,
	Michelle Lin <michelle.linto91@gmail.com>,
	Erik Schilling <erik.schilling@linaro.org>
Subject: Re: [OE-core] [PATCH 2/2] uki.bbclass: add class for building Unified Kernel Images (UKI)
Date: Mon, 2 Sep 2024 17:14:59 +0300	[thread overview]
Message-ID: <ZtXIY7nwRpNJSVmx@nuoska> (raw)
In-Reply-To: <17F16FAE8869E0F4.11433@lists.openembedded.org>

Hi,

On Mon, Sep 02, 2024 at 04:15:21PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> On Mon, Sep 02, 2024 at 03:03:45PM +0200, Alexander Kanavin wrote:
> > On Mon, 2 Sept 2024 at 14:25, Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
> > > I've checked and I have not found matching examples. We have everything working
> > > for UEFI secure boot for multiple ARM64 boards and qemu, including oeqa runtime tests.
> > > Currently the qemu side changes to support UEFI secure boot are queued to meta-arm[1].
> > > They could in theory be proposed to poky as well but there is no
> > > matching machine config for that. meta-arm provides u-boot and many other
> > > firmware SW components, including fTPM. ovmf seems to be only for x86,
> > > same for the meta-secure-core side examples for UEFI secure boot.
> > >
> > > systemd uki support is really generic and not at all specific to arm
> > > architectures. That's why I think it belongs to poky. Yes, the tests
> > > need to be somewhere else currently unless test target HW already
> > > has UEFI compatible firmware, but even with that the deployment of
> > > signing keys/certs needs to be done separately.
> > >
> > > [1] https://lists.yoctoproject.org/g/meta-arm/topic/patch_v4_00_13/108164747
> > 
> > I've checked now. There is support for UKI in
> > scripts/lib/wic/plugins/source/bootimg-efi.py
> > 
> > and there's a test for it in
> > 
> > meta/lib/oeqa/selftest/cases/wic.py (see
> > test_efi_plugin_unified_kernel_image_qemu)
> > meta-selftest/wic/test_efi_plugin.wks
> > 
> > Which begs the question: why add the class at all? Does it do
> > something that can't be done by extending wic code? Can you adapt your
> > work to use the wic plugin using the above as example?
> 
> Well, I wasn't aware of those implementations nor do I know how to use them.
> 
> I can try to figure out.

So, this is a wic image format specific re-implementation of systemd ukify.py script.
Calling not systemd ukify.py but objcopy directly. No control over kernel command
line, but could possible be added with simple patch. I don't see how to hook uki
signing into the mix with custom keys. Maybe a post processing step to the .wic
image build.

Since this version is merged I presume ukify.bbclass will be rejected.

systemd is the origins of UKI spec and they host the reference implementation
in ukify.py. I would prefer to use those.

I went through quite some pain when getting uki.bbclass to work with TPM devices and
dm-verity from meta-security which involved splitting image into dm-verity image
and .wic image recipes. Now this .wic format specific implementation could
help there, but still leaves kernel command line and signing open. I would
like to upstream these setups so that other users could also implement
secure boot with UEFI all the way to userspace. Testing with qemuarm64 and UEFI
firmware from meta-security based on u-boot is rather straight forward once
details like where to store/generate signing keys are sorted out.

Cheers,

-Mikko


  parent reply	other threads:[~2024-09-02 14:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02 10:58 [PATCH 0/3] systemd uki support Mikko Rapeli
2024-09-02 10:58 ` [PATCH 1/2] systemd-boot-native: add runtime dependency to python3-pefile-native Mikko Rapeli
2024-09-02 10:58 ` [PATCH 2/2] uki.bbclass: add class for building Unified Kernel Images (UKI) Mikko Rapeli
2024-09-02 11:11   ` [OE-core] " Alexander Kanavin
2024-09-02 11:23     ` Mikko Rapeli
2024-09-02 12:01       ` Alexander Kanavin
2024-09-02 12:25         ` Mikko Rapeli
2024-09-02 13:03           ` Alexander Kanavin
2024-09-02 13:15             ` Mikko Rapeli
     [not found]             ` <17F16FAE8869E0F4.11433@lists.openembedded.org>
2024-09-02 14:14               ` Mikko Rapeli [this message]
2024-09-02 14:30                 ` Alexander Kanavin
2024-09-04  7:56                   ` Mikko Rapeli
2024-09-04  9:17                     ` Alexander Kanavin
2024-09-04 10:04                       ` Mikko Rapeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZtXIY7nwRpNJSVmx@nuoska \
    --to=mikko.rapeli@linaro.org \
    --cc=alex.kanavin@gmail.com \
    --cc=erik.schilling@linaro.org \
    --cc=michelle.linto91@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.