The Secure Boot code currently reads the kernel from disk, validates the
signature and then reads it from disk again. A sufficiently exciting storage
device could modify the kernel between these two events and trigger the
execution of an untrusted kernel. Avoid re-reading it in order to ensure
this isn't a problem, and in the process speed up boot by not reading the
kernel twice.
If grub is signed with a key that's in the trusted EFI keyring, an attacker
can point a boot entry at grub rather than at shim and grub will fail to
locate the shim verification protocol. This would then allow booting an
arbitrary kernel image. Fail validation if Secure Boot is enabled and we
can't find the shim protocol in order to prevent this.
