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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#206282): https://lists.openembedded.org/g/openembedded-core/message/206282 Mute This Topic: https://lists.openembedded.org/mt/109169005/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
