rhboot / rhboot/shim

No attempt to load MOK with fedora's shim-15.4-4 and httpboot

Open
#436 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
1.1k
Forks
348
PR merge metrics
No merged PRs in 30d

Description

Greetings,

I'm trying to set up custom netboot with secureboot and HTTP. I'm setting dhcp bootfile to: "http://servername/path/BOOTX64.EFI" which is the shim.
Start the VM, it loads the shim. Then shim tries to load "http://servername/path//grubx64.efi". If I put a custom selfsigned binary in there, then it obviously fails to load and shim displays "access violation [OK]". But once I press OK once, it displays it again, and once I do it once more, it prints a few lines about "start_image blah security violation" and exits. It's almost like https://github.com/rhboot/shim/blob/main/shim.c#L1122 here instead of the MOK_MANAGER it tries to load second_stage again
If I tcpdump all network traffic, I see that when I press OK it actually tries load grubx64.efi again, not mmx64.efi. In fact, it never tries to load anything besides grubx64.efi. I tried renaming mmx64 to grubx64 and it successfully loads it.

So my questions are:

  • is it a known issue with known fix?
  • is there newer signed shim that I can test that might not have this problem?

Thanks

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with shim.c around line 1122 and reproduce the Fedora shim-15.4-4 HTTPBoot flow described here. Use tcpdump to compare requests for grubx64.efi and mmx64.efi after the access-violation prompt; done means identifying why MOK_MANAGER is not attempted and confirming a fix or documenting the limitation.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
operating-systems, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.