Updated support for SHIM on RISC-V #641

brianredbeard · 2024-02-23T23:46:52Z

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.

Add what is needed to build on riscv64. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> This is an update to rhboot#420 which brings it in alignment with the current upstream. Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>

brianredbeard · 2024-02-23T23:53:04Z

@vathpela can we get a review?

brianredbeard · 2024-02-29T18:36:42Z

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 · 2024-03-25T19:16:59Z

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 · 2024-03-25T19:21:27Z

Make.defaults

+	ARCH_GNUEFI		?= riscv64
+	ARCH_SUFFIX		?= riscv64
+	ARCH_SUFFIX_UPPER	?= RISCV64
+	FORMAT			:= -O binary


We had some discussions with Peter Jones last year. There was a strong preference not to add more "-O binary" architectures. Two patches landed in binutils 2.42:
[PATCH] Add basic support for RISC-V 64-bit EFI objects
[PATCH] Handle "efi-app-riscv64" and similar targets in objcopy. // From Peter Jones

That means we have efi-app-riscv64 support. That probably means it should look more like aarch64. I haven't looked deeper or tested it.

@davidlt Shim has an .sbat section with the contents of a CSV file for defining the security patch level. How would you create that section with binutils' efi-app-riscv64 target?

The content of the .sbat section is something like:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.8-0ubuntu1,https://www.ubuntu.com/

It really seems that the lines

+ FORMAT := -O binary + SUBSYSTEM := 0xa + ARCH_LDFLAGS += --defsym=EFI_SUBSYSTEM=$(SUBSYSTEM) + TIMESTAMP_LOCATION := 72

are not needed. SUBSYSTEM defaults to 0x0a in branch main of https://github.com/rhboot/gnu-efi.git:

gnu-efi/gnuefi/crt0-efi-riscv64.S:20:
#define EFI_SUBSYSTEM 10

TIMESTAMP_LOCATION is unused.

FORMAT is a flag passed to riscv64-linux-gnu-objcopy which seems unneded.

@brianredbeard Could you please drop the lines from your merge request.

@davidlt

@davidlt and @xypron pointed out prior changed to binutils 2.42 which added support for RISC-V EFI objects. This reflects the upstream preference to avoid adding additional architectures which are emitting flat binary files via `objcopy` (i.e. `-O binary` architectures).

davidlt · 2024-03-27T17:11:34Z

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

juliakreger · 2024-04-03T13:44:15Z

shim.h

@@ -128,6 +128,21 @@
 #endif
 #endif

+#if defined(__riscv) && __riscv_xlen == 64
+#ifndef DEFAULT_LOADER
+#define DEFAULT_LOADER L"\\grubriscv64.efi"


Shouldn't the file name be shorter (as in 8.3 format) given a FAT filesystem?

FAT supports long file names since Windows 95.

The default name for EFI binaries on RISC-V is /EFI/BOOT/BOOTRISCV64.EFI. That is not 8.3 either.

Distros like Fedora and Ubuntu are already using grubriscv64.efi as file name (cf. https://fedoraproject.org/wiki/Architectures/RISC-V/GRUB2)

Okay, cool. I was just thinking I've seen some vendors expect/model on it being strict FAT12 in the x86 space, and seeing the longer file name started to bug me. Also interesting Ubuntu beat Debian since I checked Debian packaging yesterday when the question came up in another project of "what would the filename be?!" so we could correctly account for it.

UEFI requires support for FAT long filenames (LFN) in all FAT12, FAT16 and FAT32 so it's fine

andreabolognani · 2024-06-21T12:57:37Z

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 · 2024-06-24T07:39:38Z

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.

Move to updated gnu-efi https://github.com/ncroxon/gnu-efi
Use gmbr3/gnu-efi@eecb589 referenced on Move riscv64 crt0 to objcopy ncroxon/gnu-efi#11
Apply the commits from this pull request
Sync the changes from gnu-efi elf_riscv64_efi.lds to shim
other changes/workarounds. (my guess is jmontleon@44d7f95 is probably the worst issue to contend with)

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 · 2024-06-24T07:45:52Z

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 · 2024-06-24T08:13:28Z

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 · 2024-06-24T09:25:51Z

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.

jmontleon · 2024-07-08T16:55:09Z

ncroxon/gnu-efi#34 was merged.

Using that work and this PR I had to make a few changes to get things working properly.
main...jmontleon:shim:riscv

I also ended up having to reimplement the closed PR #410. I did see the note re: patching gnu-efi instead of shim, which would basically be undoing the CHAR8 commit (ncroxon/gnu-efi@ce1ec9d) if that approach is desired.

gmbr3 · 2024-07-09T16:24:54Z

undoing the CHAR8 commit (ncroxon/gnu-efi@ce1ec9d) if that approach is desired.

I doubt it. SHIM and SHIM's gnu-efi is outdated and in a very inconsistent state. CHAR8 should be 'unsigned char' since that's how UEFI spec says it is.

brianredbeard force-pushed the riscv-shim branch from 144f786 to debe983 Compare February 23, 2024 23:47

brianredbeard force-pushed the riscv-shim branch from debe983 to 5031a99 Compare February 29, 2024 18:10

davidlt reviewed Mar 25, 2024

View reviewed changes

juliakreger reviewed Apr 3, 2024

View reviewed changes

gmbr3 mentioned this pull request May 7, 2024

Move riscv64 crt0 to objcopy ncroxon/gnu-efi#11

Closed

andreabolognani mentioned this pull request Jun 27, 2024

Questions about security requiremements riscv-non-isa/riscv-server-platform#18

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updated support for SHIM on RISC-V #641

Updated support for SHIM on RISC-V #641

brianredbeard commented Feb 23, 2024

brianredbeard commented Feb 23, 2024

brianredbeard commented Feb 29, 2024

davidlt commented Mar 25, 2024

davidlt Mar 25, 2024

xypron Mar 26, 2024 •

edited

Loading

xypron Mar 26, 2024

davidlt commented Mar 27, 2024

juliakreger Apr 3, 2024

xypron Apr 3, 2024

juliakreger Apr 3, 2024

gmbr3 Apr 13, 2024 •

edited

Loading

andreabolognani commented Jun 21, 2024

jmontleon commented Jun 24, 2024

julian-klode commented Jun 24, 2024

xypron commented Jun 24, 2024 via email

andreabolognani commented Jun 24, 2024

jmontleon commented Jul 8, 2024

gmbr3 commented Jul 9, 2024

Updated support for SHIM on RISC-V #641

Are you sure you want to change the base?

Updated support for SHIM on RISC-V #641

Conversation

brianredbeard commented Feb 23, 2024

brianredbeard commented Feb 23, 2024

brianredbeard commented Feb 29, 2024

davidlt commented Mar 25, 2024

davidlt Mar 25, 2024

Choose a reason for hiding this comment

xypron Mar 26, 2024 • edited Loading

Choose a reason for hiding this comment

xypron Mar 26, 2024

Choose a reason for hiding this comment

davidlt commented Mar 27, 2024

juliakreger Apr 3, 2024

Choose a reason for hiding this comment

xypron Apr 3, 2024

Choose a reason for hiding this comment

juliakreger Apr 3, 2024

Choose a reason for hiding this comment

gmbr3 Apr 13, 2024 • edited Loading

Choose a reason for hiding this comment

andreabolognani commented Jun 21, 2024

jmontleon commented Jun 24, 2024

julian-klode commented Jun 24, 2024

xypron commented Jun 24, 2024 via email

andreabolognani commented Jun 24, 2024

jmontleon commented Jul 8, 2024

gmbr3 commented Jul 9, 2024

xypron Mar 26, 2024 •

edited

Loading

gmbr3 Apr 13, 2024 •

edited

Loading