Add riscv64 support

[andreabolognani]

This is part of an attempt to bring riscv64 support into shim.

See #420 and #641 for previous discussion, as well as #777 which is a prerequisite of this PR.

Using this branch I was able to successfully build shim on both x86_64 and riscv64, and I was able to use the resulting binaries to boot Fedora 42 cloud images for both architectures, replacing the stock ones.

[andreabolognani]

Tagging @xypron, @brianredbeard and @jmontleon since some of the changes come from them.

[andreabolognani]

Rebased on top of #777.

Additionally, I have dropped all definitions related to va_list from shim's stdarg.h since they no longer appear to be necessary when using the latest upstream version of gnu-efi. I believe their existence was a point of contention in the past.

@xypron perhaps you could revisit your patch, integrating the follow-up fixes and improvements from me, @brianredbeard and @jmontleon? And of course any feedback from @vathpela would be much appreciated too :)

Thanks in advance!

[andreabolognani]

Rebased to match the current contents of the main branch, matching #777. Fixed a couple of signoffs with the author's explicit agreement.

[andreabolognani]

Rebased once again on top of the updated #777. Squashed some patches (with agreement from the authors) and fixed VPATH builds.

[andreabolognani]

Rebased on top of #777 and added CI jobs for riscv64 cross-builds.

[andreabolognani]

Rebased on top of #777 once again.

[andreabolognani]

@xypron can you please consider giving this some sprucing up? The CI now passes and #777 looks close to being ready. You can feel free to squash any changes of my own into your commit, and I'm pretty confident neither @brianredbeard nor @jmontleon would mind if you did the same with theirs. Thanks!

[brianredbeard]

I've got one thing for you to cherry-pick: brianredbeard@29593a0

The TL;DR is that .vendor_cert, .data.ident, and .sbatlevel. These sections hold (respectively) the embedded vendor certificates, the SBAT relocation level data, and the build identity information. Makefile:281-284 uses objcopy to extract these values from the elf to produce the PE image and without building that correctly we would end up dropping the data.

Not having the cert verification or revocation would probably defeat the point of what we're working on 😆

Like my previous attempt, I'm happy to play janitor and do the clean-up step as we go.

[brianredbeard]

I've worked through #777 and this one (#778) I've done a review, found and fixed several issues, and rebased the combined work into a cleaner commit series.

Issues fixed in the riscv64 linker script (elf_riscv64_efi.lds):

• Added missing .vendor_cert, .sbatlevel, and .data.ident output sections (these were never carried over from the gnu-efi 4.0.4 template, breaking vendor cert verification, SBAT variable payload, and version identification)
• Merged .rodata into .data to match all other shim architectures
• Fixed ALIGN(512) → page-aligned _edata placement
• Removed manual _DYNAMIC definition and unnecessary KEEP on .reloc
• These were all artifacts of copying the gnu-efi 4.0.4 script without applying shim's standard adaptations — the same adaptations already made for x86_64, ia32, and aarch64

Commit structure (4 commits, down from 19):

1. gnu-efi: Update to upstream 4.0.4 — submodule switch + all API migrations (ReallocatePool, CompareGuid, VPrint, stdarg, string signedness)
2. Linker scripts: Fix section ordering and cleanup — .reloc reorder, .eh_frame/.build-id dedup, ARM .areloc
3. Add RISC-V 64-bit (riscv64) architecture support — corrected linker script, PE/COFF support, build system, icache flush
4. CI: Add riscv64 cross-build jobs

All original authors are preserved via --author, Co-Authored-By, and Signed-off-by. The final tree is identical to the current HEAD of #778 except for the linker script fixes and a minor whitespace fix in peimage.h. The same whitespace nit effects the ARM entry (a tab instead of spaces as per all other entries). I can take care of fixing that too if folks please.

Branch is at https://github.com/brianredbeard/redhat-efi-boot-shim/tree/riscv-squash — happy to open a PR superseding both #777 and #778 if that works for everyone.

One note, the current tag for the submodule is master and not 4.0.4 (or the proper tag/branch). I just want to confirm that's correct.

[andreabolognani]

@brianredbeard thanks a lot for taking a look!

I've checked out your squash branch and I have to say that I'm personally not a big fan of lumping so many changes together into a small number of large commits: I much prefer having a larger number of smaller commits.

The exception to the above is when you have a commit that introduces a change, only for the next commit to (partially) undo it. That's very much the case here, mostly on account of @xypron providing the original implementation and several other people adding fixes and improvements on top. In this specific scenario, I would welcome squashing some of the commits together to avoid unnecessary churn. But then, the original implementation could itself potentially use some splitting into smaller incremental steps...

Anyway, I've cherry-picked your additional changes for now. Ultimately it's up to the maintainers whether they would rather have many small commits or few large ones, and I'd be happy to go in either direction once they will have made their preference known.

[andreabolognani]

#777 is already organized pretty much optimally as far as I'm concerned, and there are no functional changes that you're proposing for that part, so I just left it alone. The whitespace changes you mentioned and any other cleanups should IMO be made as a follow-up, to avoid potentially holding up the functional parts due to disagreements on non-functional concerns.

[andreabolognani]

Rebased on top of main now that #777 has been merged.

@xypron can you please take another look at this? The coast is finally clear for getting it merged, it just need a bit of tidying up.

In particular we want to avoid the situation where some code is introduced in one commit only to be dropped/altered in a follow-up one. Makes the git history confusing for no particular good reason. I think commits 2-6 should definitely be squashed into commit 1; jury's out when it comes to commits 7 and 8. It would be perfectly fine IMO to just squash the whole thing together, unless the maintainers disagree with that approach.

The DCO job complains about git authorship information disagreeing with the signoff. That will need to be fixed too.

I can take care of all of the above myself if that's more convenient for you. Just let me know which of the two email addresses should be associated with the change, and I'll do the rest.

Thanks!

[xypron]

@andreabolognani

Thank you for driving this. Please, use my Canonical email address.

I have added reviewing the series to next weeks Jira cards.

[andreabolognani]

@xypron fantastic!

I've squashed everything together, made a couple tiiiiiny whitespace tweaks, and adjusted authorship information. Once you get a chance to look at the results, if there are any further changes that you think are necessary, we can figure out how to go about them.

... and of course in the time between the previous update to the PR and now, Debian testing has become broken somehow and all mkosi jobs are failing :) We'll figure that out too.

[xypron]

Hello @andreabolognani,

Without POST_PROCESS_PE_FLAGS='-n' I see these build warning:

./post-process-pe -vv shimriscv64.efi
validate_nx_compat():379: NX Compatibility flag is not set

./post-process-pe -vv mmriscv64.efi
validate_nx_compat():379: NX Compatibility flag is not set

./post-process-pe -vv fbriscv64.efi
validate_nx_compat():379: NX Compatibility flag is not set

The only executable section is (as reported by efi_analyzer):

Section[1]: .text
Virtual size: 0x4f930
Virtual address: 0x1e000
Size of raw data: 0x50000
Pointer to raw data: 0x1a000
End of raw data: 0x6a000
Characteristics: 0x60000020
* The section contains executable code.
* The section can be executed as code.
* The section can be read.

Hence the NX Compatibility flag should be set. gnu-efi/riscv64/gnuefi/crt0-efi-riscv64.S would be the place to do so.
I think we should add a patch to upstream gnu-efi to set the flag in files gnu-efi/riscv64/gnuefi/crt0-efi-*.S to avoid having to set it via POST_PROCESS_PE_FLAGS.

Best regards

Heinrich

[andreabolognani]

@xypron thanks for checking things out!

A lot of this goes over my head, so please help me understand. Is the "NX Compatibility flag" something that is necessary for basic enablement, or could we realistically leave things as they are for now and fix things with a follow-up? What's the actual impact from it being missing?

I think getting gnu-efi patched and bumping the dependency on the shim side would be relatively straightforward now that we're tracking upstream more closely, but I'm still somewhat wary of introducing an additional step now that we're finally so tantalizingly close to getting riscv64 support merged.

So if that could be done as a follow-up enhancement, I would probably prefer going that route. But I'll trust your judgement on whether that's actually feasible.

Did you spot any other issues, or are you otherwise happy with the PR?

Thanks again!

[xypron]

@andreabolognani
The requirement by Microsoft is that EFI binaries should not have sections that are both executable and writable. Such binaries should be rejected in a secure boot scenario. The NX flag in the PE-COFF header is used as a signal that the condition is met. We should set it for shim, GRUB, and the kernel.

[andreabolognani]

@xypron okay so IIUC it's a requirement for Secure Boot specifically, not for basic operations of shim (loading grub, running the fallback boot path).

If that's the case, considering that there is still no agreement on who should even sign the shim binary in the context of Secure Boot on riscv64, I'd be inclined to not consider that a blocker and proceed with the PR as is.

Perhaps in the meantime you could open a PR against gnu-efi that introduces the necessary changes? That would get the ball rolling for NX as a follow-up improvement.

[xypron]

Perhaps in the meantime you could open a PR against gnu-efi that introduces the necessary changes? That would get the ball rolling for NX as a follow-up improvement.

Sounds good

[andreabolognani]

Attempting to fix / work around the issue currently preventing all mkosi jobs from running. If it works, I will open a separate PR for it.

[xypron]

Thank you @andreabolognani for pushing this forward.

With signed shim, grub, kernel and a security database (PK, KEK, db) in U-Boot secure boot is working:

[    0.000000] Linux version 7.0.0-14-generic (buildd@bos03-riscv64-054) (riscv64-linux-gnu-gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0, GNU ld (GNU Binutils for Ubuntu) 2.46) #14.2-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 17 12:35:32 UTC 2026 (Ubuntu 7.0.0-14.14.2-generic 7.0.0)
...
[    0.000000] secureboot: Secure boot enabled
[    0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
...
Welcome to Ubuntu 26.04 LTS!

With a byte changed in grubriscv64.efi:

                    ERROR
Verification failed: (0x1A) Security Violation

LGTM

P.S. Most of the test preparation steps are available in https://github.com/xypron/test-shimriscv64.git

[andreabolognani]

@xypron great to hear that!

The tentative changes I've made to the mkosi configuration seem to have restored CI to its previous state: two of the CentOS jobs are still failing, but we already knew about that and a fix is supposed to be in the works. I will prepare a separate PR for those changes.

We should still look into getting NX wired up properly. Please tag me in the gnu-efi PR when you get around to creating it. I'll keep an eye on it and look into following up on the shim side once it has landed.

[xypron]

@andreabolognani
NX can be set via environment variable POST_PROCESS_PE_FLAGS='-n' during the shim build process.
There is also POST_PROCESS_PE_FLAGS='-N' to remove the flag.

Changing the default in gnu-efi makes sense but is orthogonal to this pull request.

[andreabolognani]

@xypron based on the documentation, $POST_PROCESS_PE_FLAGS appears to be intended as an override mechanism for end users and distro packagers. No existing architecture is using it. So it seems to me that modifying gnu-efi is the proper way to go about it.

@vathpela can you please take a look at #806 (which contains the same CI changes mentioned earlier) and another look at this one? Given Heinrich's positive feedback, it should be possible to merge it now. And considering that all the changes made to common code are merely adding riscv64-specific branches, without touching the existing architectures at all, it should be entirely safe to do so.

Thanks!

[xypron]

@andreabolognani

Looking at the gnu-efi code a bit deeper. HAVE_EFI_OBJCOPY is set for riscv64. This means the value of DllCharacteristics is not defined via gnuefi/crt0-efi-riscv64-local.S but provided by the toolchain. Only armv7 and mips use local crt0 files, assuming binutils >= 2.38. So setting the NX flag in shim make sense.

[andreabolognani]

@xypron I'm all for that, but unclear on how to make it happen cleanly. $POST_PROCESS_PE_FLAGS doesn't seem like the way to go for all the reasons I mentioned earlier. How do other architectures handle this? I've poked around a bit and I haven't been able to figure it out so far.

[xypron]

@andreabolognani

Ubuntu 26.10 carries a patch
https://git.launchpad.net/ubuntu/+source/shim/tree/debian/patches/Build-an-additional-NX-shim-mark-MokManager-and-Fallback-.patch which builds both a version of shim with NX flag and one without. The build parameter POST_PROCESS_PE_FLAGS=-n is used for the NX version.

OpenSuSE Leap shim-16.1-2.2.aarch64.rpm and Fedora shim-x64-16.1-7.x86_64.rpm don't set the NX flag.

[andreabolognani]

@xypron thanks for providing that pointer!

It looks like Debian also uses POST_PROCESS_PE_FLAGS=-n to enable NX, see debian/rules#L48-49.

In both all cases seen so far the change happens at the distro package level, and it's applied regardless of architecture. So it appears to me that we don't really need to do anything in shim itself? Please let me know if I've missed anything.