Re: [OE-core] [PATCH v10 0/9] systemd uki support

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2024-10-24 at 11:55 +0300, Mikko Rapeli wrote:
> On Wed, Oct 23, 2024 at 07:39:51PM +0100, Richard Purdie wrote:
> > On Wed, 2024-10-23 at 17:58 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Wed, 2024-10-23 at 17:44 +0100, Richard Purdie via
> > > lists.openembedded.org wrote:
> > > > On Wed, 2024-10-23 at 15:08 +0300, Mikko Rapeli via
> > > > lists.openembedded.org wrote:
> > > > > These changes enable building systemd uki images which combine
> > > > > kernel, kernel command line, initrd and possibly signatures to
> > > > > a single UEFI binary. This binary can be booted with UEFI
> > > > > firmware
> > > > > and systemd-boot. No grub is needed and UEFI firmware and/or
> > > > > systemd-boot provide possibilities for boot menus.
> > > > > The uki binary can also be signed for UEFI secure boot
> > > > > so the secure boot extends from firmware to kernel and initrd.
> > > > > Binding secure boot to full userspace is then easier since for
> > > > > example
> > > > > kernel command line and initrd contain the support needed to
> > > > > mount
> > > > > encrypted dm-verity etc partitions, and/or create partitions on
> > > > > demand
> > > > > with systemd-repart using device specific TPM devices for
> > > > > encryption.
> > > > > 
> > > > > Tested on qemuarm64-secureboot machine from meta-arm with changes
> > > > > to
> > > > > support secure boot. Slightly different configuration tested on
> > > > > multiple arm64 System Ready boards with UEFI firmware, real and
> > > > > firmware
> > > > > based TPM devices. Tested with ovmf firmware on x86_64 with
> > > > > selftests but
> > > > > without secure boot which seems to be harder to setup in ovmf.
> > > > > 
> > > > > Sadly I see two wic selftests, wic.Wic2.test_rawcopy_plugin_qemu
> > > > > and
> > > > > wic.Wic2.test_expand_mbr_image, failing when executing all wic
> > > > > selftests
> > > > > on a build machine with zfs filesystem. Will investigate this
> > > > > further.
> > > > > The issue seems to be in mkfs.ext4 producing broken filesystem,
> > > > > and
> > > > > partially
> > > > > in the tests which don't run the correct rootfs file (.ext4 vs
> > > > > .wic).
> > > > > Will debug this further and it is IMO unrelated to these changes
> > > > > since
> > > > > they reproduce on pure master branch without this series.
> > > > > 
> > > > > v10: disabled kvm support in new tests since it breaks qemu boot
> > > > > on
> > > > > aarch64
> > > > >      build machine, removed "testimage" from IMAGE_CLASS as well
> > > > > since
> > > > >      can end up testing qemu machine during build.
> > > > 
> > > > I hate to say this but
> > > > wic.Wic2.test_efi_plugin_plain_systemd_boot_qemu_aarch64 is still
> > > > failing:
> > > > 
> > > 
> > > https://valkyrie.yoctoproject.org/#/builders/23/builds/320/steps/14/logs/stdio
> > 
> > and:
> > 
> > https://valkyrie.yoctoproject.org/#/builders/23/builds/323/steps/14/logs/stdio
> > 
> > which is clearer without the other failure.
> 
> Comparing x86_64 and aarch64 build host runqemu command lines from
> wic.Wic2.test_efi_plugin_plain_systemd_boot_qemu_aarch64 selftest,
> two things pop up.
> 
> aarch64 still enables KVM via "-enable-kvm". This is despite QEMU_USE_KVM = ""
> in the bitbake build config. Oh, this is only applied to the build configuration
> and bitbake build command but removed before runqemu is called. I can try to apply
> this config also for runqemu. This pattern is used in several tests. Build config
> is set temporarily and then removed before calling runqemu. I'll send a separate
> patch to master-next to reduce spam.
> 
> aarch64 host uses "-cpu host" with qemu while x86_64 sets the CPU variant explicitly
> to "-cpu cortex-a76". I can't see from build logs which CPU variant the
> host really is. There are a lot of CPU variants in aarch64 world and I don't think
> they are all compatible, or detect CPU features at runtime which can impact
> things like firmware code badly. I don't know how to fix this.

Well spotted! I'm running a test build with your patch:

https://valkyrie.yoctoproject.org/#/builders/23/builds/329

The CPU info is:

$ cat /proc/cpuinfo 
processor	: 0
BogoMIPS	: 50.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x3
CPU part	: 0xd0c
CPU revision	: 1


$ lscpu 
Architecture:             aarch64
  CPU op-mode(s):         32-bit, 64-bit
  Byte Order:             Little Endian
CPU(s):                   80
  On-line CPU(s) list:    0-79
Vendor ID:                ARM
  Model name:             Neoverse-N1
    Model:                1
    Thread(s) per core:   1
    Core(s) per socket:   80
    Socket(s):            1
    Stepping:             r3p1
    Frequency boost:      disabled
    CPU max MHz:          3000.0000
    CPU min MHz:          1000.0000
    BogoMIPS:             50.00
    Flags:                fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
Caches (sum of all):      
  L1d:                    5 MiB (80 instances)
  L1i:                    5 MiB (80 instances)
  L2:                     80 MiB (80 instances)
NUMA:                     
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-79
Vulnerabilities:          
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; __user pointer sanitization
  Spectre v2:             Mitigation; CSV2, BHB
  Srbds:                  Not affected
  Tsx async abort:        Not affected