search

rhboot / shim

UEFI shim loader
Other
816 stars 284 forks source link

Updated support for SHIM on RISC-V #641

Open brianredbeard opened 4 months ago

brianredbeard commented 4 months ago

Add what is needed to build on riscv64.

Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com

This is an update which supersedes #420 which brings it in alignment with the current upstream and fixes a minor style nit around the definition of __riscv.

brianredbeard commented 4 months ago

@vathpela can we get a review?

brianredbeard commented 4 months ago

FYI, reverted the previous commit after a discussion with @xypron. Heinrich helpfully pointed out that the structure of pre-processor definitions in the form of __riscv is (tragically) required due to definitions in GCC.

davidlt commented 3 months ago

FYI gnu-efi ( https://github.com/rhboot/gnu-efi/tree/master ) has been rebased to 3.0.18 (released 3 days ago!). The builds are already available for F40 and F41 in Fedora too: F40: https://koji.fedoraproject.org/koji/buildinfo?buildID=2426104 F41: https://koji.fedoraproject.org/koji/buildinfo?buildID=2426088

davidlt commented 3 months ago

The last commit is missing Signed-off-by: based on the review. How sure how important that is.

andreabolognani commented 2 weeks ago

Hey, I'm wondering what's missing to get this one merged at this point? From a cursory look, it seems that all points raised during review have been addressed.

I'm really keen on seeing this make its way to Fedora. Along with the lack of an up-to-date GRUB2 (which is something that's supposedly being addressed as we speak), not having shim is, at least as far as I'm aware, the last remaining blocker to producing usable (albeit still unofficial) Fedora images for RISC-V.

jmontleon commented 1 week ago

It is not very clean, but I was able to build and boot shim on a VisionFive 2 and EDK2 on a qemu/libvirt VM. I forked shim and gnu-efi with some rough work

I had to pull a few things together to get builds working on riscv64.

You can basically clone https://github.com/jmontleon/shim/tree/riscv and cd shim && make clean && make && sudo cp shimriscv64.efi /boot/efi/EFI/BOOT/BOOTRISCV64.EFI && sudo cp fbriscv64.efi /boot/efi/EFI/BOOT/ && sudo cp shimriscv64.efi /boot/efi/EFI/fedora/

With /boot/efi/EFI/fedora/BOOTRISCV64.csv containingshimriscv64.efi,Fedora,,This is the boot entry for Fedora the system boots and you get a boot entry created.

julian-klode commented 1 week ago

Hey, I'm wondering what's missing to get this one merged at this point? From a cursory look, it seems that all points raised during review have been addressed.

I'm really keen on seeing this make its way to Fedora. Along with the lack of an up-to-date GRUB2 (which is something that's supposedly being addressed as we speak), not having shim is, at least as far as I'm aware, the last remaining blocker to producing usable (albeit still unofficial) Fedora images for RISC-V.

I don't think any distro has intentions to sign anything for RISC-V yet and I don't know if Microsoft would even accept it, or what the value would be in handing Microsoft the control over the RISC-V CA too.

And unsigned you can just use grub directly and be happy, so I think there's no value merging changes like this and adding the maintenance overhead or have it potentially break each release because nobody tests it.

xypron commented 1 week ago

Am 24. Juni 2024 09:46:14 MESZ schrieb Julian Andres Klode @.***>:

Hey, I'm wondering what's missing to get this one merged at this point? From a cursory look, it seems that all points raised during review have been addressed.

I'm really keen on seeing this make its way to Fedora. Along with the lack of an up-to-date GRUB2 (which is something that's supposedly [being @.***/thread/PHGU7UQS6O5SLLZIWTVD3E73OTM4GCS7/) as we speak), not having shim is, at least as far as I'm aware, the last remaining blocker to producing usable (albeit still unofficial) Fedora images for RISC-V.

I don't think any distro has intentions to sign anything for RISC-V yet and I don't know if Microsoft would even accept it, or what the value would be in handing Microsoft the control over the RISC-V CA too.

Testing should be done in the CI. There is no need for Microsoft signing for testing.

There has not been any decision on a global signing authority yet.

We should avoid development after the hardware is out. Instead we should provide the RISC-V community the tools needed to test secure boot now. This does not imply that distros have to package it now.

Best regards

Heinrich

And unsigned you can just use grub directly and be happy, so I think there's no value merging changes like this and adding the maintenance overhead or have it potentially break each release because nobody tests it.

andreabolognani commented 1 week ago

And unsigned you can just use grub directly and be happy, so I think there's no value merging changes like this and adding the maintenance overhead or have it potentially break each release because nobody tests it.

AFAIK shim doesn't just handle the Secure Boot part though, it also takes care of locating and running the GRUB binary when installed as the fallback entry (${ESP}/BOOT/BOOTRISCV64.EFI). At least that's how things seem to work in Fedora, though admittedly the Debian/Ubuntu boot path appears to be set up differently.

Anyway, that's the part I'm interested in, as it would allow us to ship disk images that can be booted right away, without the need on the user's part to create UEFI boot entries themselves,

For this to work there's no need for the shim binary to be signed, much less to determine who the signing entity would be.