No attempt to load MOK with fedora's shim-15.4-4 and httpboot
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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