Comment 12 for bug 1711203
Revision history for this message
| Mathieu Trudel-Lapierre (cyphermox) wrote | #12 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
I don't think this requires gsbx64.efi at all, it looks to me like a different issue; but one that we'd likely hit in the future anyway when enforcing signatures on kernels.
So, how this works is that a shim retrieved over TFTP loads a grub retrieved over TFTP, which is provided some config that tells it to chainload more stuff (in the "boot from disk" case which is failing here).
Since booting straight to disk, with SB enabled, we can infer that the portion on disk of the chain is valid and working correctly -- otherwise you would have validation failures when trying that.
I can only work with the assumption that all the bits in the chain are signed either by a Microsoft key that is known by the firmware (for shim), or by the Canonical key (which itself is known by shim) in the case of grub. Everything is signed, so there's no reason for things to fail validation -- it has to be that something isn't validating signatures.
Now, that points to a grub bug, but I'm not sure how it fails here -- by my read, you'd have grub go through validating even chainloaded images for their key by asking shim to validate them. This can fail, but then we'll need the output of that boot process with:
set debug="
You set this in grub.cfg.
We don't do multiple builds of shim -- there's only one shim that exists in the archive, so it's not likely to be the culprit, and grub already manages to validate things successfully and chainload them correctly in the context of UEFI Secure Boot. This was in fact a recently fixed bug in grub that caused it to fail to chainload Windows in UEFI.
One further thing to try would be to grab grubnetx64.efi from the archive and test with replacing the grubx64.efi file in MaaS with it? That would establish that the issue is a regression in grub:
http://