Well one FAILED less at least ;-)

FAT-fs (vda1): codepage cp437 not found           
[FAILED] Failed to mount EFI System Partition Automount.
See 'systemctl status efi.mount' for details.                                                                                
random: crng init done                                        
[  OK  ] Finished Update Boot Loader Random Seed.                                                                            
[FAILED] Failed to start Automatic Boot Loader Update.                                                                       
See 'systemctl status systemd-boot-update.service' for details.                                                              

OK probably this is the reason:

# mount /dev/vda1 /boot
mount: /boot: unknown filesystem type 'vfat'.
       dmesg(1) may have more information after failed mount system call.

So the fix would be then:

diff --git a/board/x86_64/linux.config b/board/x86_64/linux.config
index fd088a5..1477d65 100644
--- a/board/x86_64/linux.config
+++ b/board/x86_64/linux.config
@@ -101,6 +101,8 @@ CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
 CONFIG_EXT4_FS=y
 CONFIG_AUTOFS_FS=y
 CONFIG_FUSE_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_FAT_DEFAULT_UTF8=y
 CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_SQUASHFS=y
 CONFIG_TRUSTED_KEYS=y

What do in my custom #BuildRoot and #systemd based image to this error:

[FAILED] Failed to mount EFI System Partition Automount.                                                                     
See 'systemctl status efi.mount' for details.                 
[  OK  ] Finished Update Boot Loader Random Seed.             
tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1)        
random: crng init done                                        
[  OK  ] Started Network Name Resolution.                                                                                    
[  OK  ] Reached target Host and Network Name Lookups.                                                                       
         Mounting EFI System Partition Automount...           
         Starting Virtual Console Setup...                    
[FAILED] Failed to mount EFI System Partition Automount.                                                                     
See 'systemctl status efi.mount' for details.                 
[FAILED] Failed to start Automatic Boot Loader Update.        
See 'systemctl status systemd-boot-update.service' for details.

I have no idea what those error messages mean.

The source is here: https://gitlab.com/jarkkojs/linux-tpmdd-test

And here’s the output for the “details”:

# systemctl status systemd-boot-update.service
× systemd-boot-update.service - Automatic Boot Loader Update
     Loaded: loaded (/usr/lib/systemd/system/systemd-boot-update.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-06-12 01:50:17 UTC; 2h 58min left
       Docs: man:bootctl(1)
    Process: 87 ExecStart=bootctl --no-variables --graceful update (code=exited, status=1/FAILURE)
   Main PID: 87 (code=exited, status=1/FAILURE)
        CPU: 28ms

Jun 12 01:50:15 tpmdd systemd[1]: Starting Automatic Boot Loader Update...
Jun 12 01:50:17 tpmdd bootctl[87]: Failed to open parent directory of "/efi": No such device
Jun 12 01:50:17 tpmdd systemd[1]: systemd-boot-update.service: Main process exited, code=exited, status=1/FAILURE
Jun 12 01:50:17 tpmdd systemd[1]: systemd-boot-update.service: Failed with result 'exit-code'.
Jun 12 01:50:17 tpmdd systemd[1]: Failed to start Automatic Boot Loader Update.

#linux #kernel #testing

I see couple of errors in the gif animation have to fix those tomorrow but good results for one day hacking anyway :-)

proof

For debugging this type of stuff for me finding this not that recent tool fatcat was essential. It extracts vfat image and that's why it is useful ;-)

The whole thing is pretty tight too now [1]

CMakeLists.txt
Config.in
LICENSE
README.md
board/x86_64/buildroot.conf
board/x86_64/genimage.cfg
board/x86_64/kselftest-tpm2.exp.in
board/x86_64/linux.config
board/x86_64/post-build.sh
board/x86_64/post-image.sh
board/x86_64/run-qemu.sh.in
board/x86_64/run-tests.sh.in
board/x86_64/ssh_config.in
configs/x86_64_defconfig
external.desc
external.mk

Goal is also to keep this recipe minimal for the sake of being robust for testing various things… I guess I can now start properly version control this and not just overwriting the history ;-)

Also since I marked this to MAINTAINERS it is better to do so but just wanted to make the baseline to the form which has a long-term future.

[1] https://gitlab.com/jarkkojs/linux-tpmdd-test

OK, cool, #systemd is booting now with systemd-#boot. The problem was simply that I did not package all the required files with #genimage :-)

Even tho this image built only for #kernel test and could in theory run just bzImage as #ELF-executable, systemd-boot makes sense given the ability to modify the kernel command-line without compiling the kernel.

So I can now conclude that I've migrated from #busybox to systemd in my kernel testing workflow :-)

#linux

OK and how does saying that help anyone?

@esmil Yep, it would be possible but overall it is more robust to pass it so I guess cmdline is actually in my case legit reason to use systemd-boot...

@cherti I don’t know, that’s why I’m asking.

In order to attest correctly it should:

1. Get CPU attestation packed into certificate periodically from the service.
2. Compare this certificate against Intel CA.

Please show where these steps are done because I’m interested…

Looking of surface better:

Extracting /EFI/BOOT/BOOTX64.EFI to tmp/EFI/BOOT/BOOTX64.EFI
Extracting /bzImage to tmp/bzImage
Extracting /LOADER/loader.conf to tmp/LOADER/loader.conf
Extracting /LOADER/ENTRIES/buildroot.conf to tmp/LOADER/ENTRIES/buildroot.conf

@esmil Thanks for your insights! Appreciate it.

@esmil I could actually do this without grub and without systemd-boot but I want to emulate the full stack for robustness sake. I.e. could just rename bzImage as BOOTx64.efi and place it correct location...

@esmil Yeah, in my case kernel-install is not useful because I build rootfs as part of the kernel build itself :-) But keeping the build as minimal as possible is good goal for sure.

@esmil I do have file systems in BuildRoot of which I do not want to get rid of :-) I.e. I have separate ESP and rootfs.

But dropping dependency from my build makes more sense.

BTW, grub-efi is just an EFI application so in that sense there is zero difference. It is more related to fatness of the stack.

And if you want just to boot a kernel without rootfs why you even would bother using systemd-boot? You can compile just as well EFI stub to the kernel image... So systemd-boot would be in such scenario useless cruft. Just rename bzImage as BOOTx64.efi and you're set. Linux *is* an EFI. application.

Anyway, I'll go with systemd-boot because I need to build less by doing that :-)

Right this tells me everything:

$ fatcat efi-part.vfat -x tmp 
Extracting /EFI/BOOT/BOOTX64.EFI to tmp/EFI/BOOT/BOOTX64.EFI
Extracting /bzImage to tmp/bzImage

I don’t know if there is any more modern tool for this but this is sometimes useful: https://github.com/Gregwar/fatcat

I'm re-formalizing my question because I could wrong too

Using any formation of #Signal App, is it possible to get #SGX #attestation of contact discovery back to the client and view the certificate, or how does it benefit the end user?

Or is from client possible to get this attestation using the raw protocol that the app uses?

Actually not yet too successful booting my #BuildRoot image with systemd-boot. With grub-efi I got to the login.

EDIT: I think I got it and it is pretty obvious. I’m still deploying GRUB style configs when I construct the disk image with genimage, so I just fix them up as systemd boot style configs (found a reference for that).

So I just follow along [1] and cross my fingers ;-) I think it is good exercise to build from scratch a systemd image from boot to user space in all cases.

[1] https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/

The summary of #systemd #spam of today:

1. I got it fully working for my #BuildRoot image build.
2. It boots with no errors.
3. Compilation time is still not much different than with #Busybox.
4. Uses now systemd-boot instead of GRUB (thanks @vathpela for comments).
5. Uses systemd version 254. Plan is to get into phase.
6. For BuildRoot, uses the master branch of: https://gitlab.com/jarkkojs/linux-tpmdd-test

I “systemd” re-initiated the history of my test repository: https://gitlab.com/jarkkojs/linux-tpmdd-test. From now on I commit on keeping a proper versions on this :-) It had no forks so far so I’m the only person who had consequences on that action.