First could not find them because I was searching for https://longhorn.ms/

Sorry do not connect Intel, Loonghorn and RISC_V to the same sentence ;-)

There's also Russian Elbrus line of CPU's but not Elbrus sold at Ali Express (unfortunately). I might have even bought one if they had that for plain interest... Loongson products I can find easily.

@vathpela @dr2chase @ariadne Yep, in the end of 2021 but how does that connect to RISC-V? :-) My experiences with RISC-V connect to this project: https://sochub.fi/. I've been on industry "sabbatical" for over a year (returning back to some yet-to-be defined company next Oct).

@vathpela @ariadne @dr2chase And RISC-V specs are as thin as they are as they are lacking proper semantics definitions, e.g. in pseudo code.

@vathpela @ariadne @dr2chase RISC-V with MMU is somewhat unfinished experiment. Hard to even say what it is really, given huge holes in the spec's and a few by definition ambiguous opcodes. Mostly RISC-V in reality is what SiFive implements :-)

I sometimes wonder why people don't just take OpenMIPS, which is almost like finished RISC-V with MMU...

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.