| Summary: | shim doesn't provide hooks for signing | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Jonathan Bittner <jbittner.br.bugs> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED MOVED | ||
| Severity: | normal | CC: | buildroot, yann.morin.1998 |
| Priority: | P5 | ||
| Version: | 2023.02 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
|
Description
Jonathan Bittner
2023-04-11 16:47:05 UTC
Jonathan, All,
> Shim is supposed to provide a signed UEFI bootloader for secureboot.
> However, it is intended to be supplied with a key at build time (make
> VENDOR_CERT_FILE=<path.to.cer>). Perhaps a menu option could be added
> to Config.in allowing the user to specify a certificate location.
As far as I understand it, this is two-fold:
1. shim can check the signature of the files it loads; this is what
VENDOR_CERT_FILE is for, and
2. shim can be signed, so that the EFI bootrom can verify shim against
known keys; this is what ENABLE_SHIM_CERT, if set, is for.
However, it is very possible to build a shim that is signed but does
not verify the signatures of what it loads, or the other way around.
So, we'd need two options:
1. BR2_TARGET_SHIM_CERT_FILE, the path to a .cer file, to set in
VENDOR_CERT_FILE; if BR2_TARGET_SHIM_CERT_FILE, the generated shim
will not check signatures of what it loads
2. BR2_TARGET_SHIM_SIGNED, a boolean to drive whether shim is signed,
in which case the *.efi.signed should be installed, along with
shim.key (so it can be enrolled into the UEFI bootloader?)
It looks like they are independent each from the other, and so can be
done in any order, and it is OK if you only send a patch for the one
you need (you'll send a patch, won't you? ;-) )
For 2, I am not sure if one can provide their own shim.key and shim.crt,
but looking at the Makefile, it looks like it should be possible (one
does not want to enroll a new key for each build!).
Regards,
Yann E. MORIN.
Thanks for your comments. Good to know about the second use case. At this time, I don't think I will use SecureBoot in my project so I don't foresee submitting any patches. Thank you for your report.
The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
https://gitlab.com/buildroot.org/buildroot/-/issues
We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.
Thank you!
|