1 Rookie
•
4 Posts
0
1379
Missing new vmlinuz-x.xx.x-xx-oem.efi.signed after kernel update
I have a new Dell Inspiron 3584 with Ubuntu 18.04 preinstalled.
I could see in the /boot directory that the installed kernel version was 4.15.0-21 and that there were also several other files with the same version.
A few days later I updated the system and, together with other package updates, also the kernel got updated to the version 4.15.0-66.
Looking again at the /boot directory, I could see that there was a new set of files with version 4.15.0-66, except for the oem.efi.signed that was missing.
I ask why the file vmlinuz-4.15.0-66-oem.efi.signed has not been generated: maybe is something wrong in the configuration?
How can I fix my system, letting generate a new oem.efi.signed file when a kernel is updated?
Many thanks!
Gilbou92
77 Posts
0
May 7th, 2020 10:00
EFI comes with SecureBoot
It uses asymetric keys to sign each step of the boot process.
The EFI firmware (which we incorrectly call BIOS, but it's not a BIOS) is applied only if signed (if Dell does things properly). Then the EFI gives control to Grub2, it checks that Grub2 signature is valid. Which means that Grub2 has been signed by the private key part of Canonical's key. If so, Grub2 takes control and looks a a kernel to boot. Grub2 will ask the EFI to check the kernel signature (if present, that .efi.signed file you're talking about) and if so, kernel takes control, boots the machine, and starts loading the kernel modules. If they are signed, this is also checked using EFI (since the public part of Canonical's key is stored in the firmware).
A machine is considered safer if at each step the signatures have been confirmed valid.
EFI loads Grub2
Grub2 loads kernel
kernel loads modules
If you are missing the .efi.signed file it means you don't have a 100 % secureboot, but partially.
This is not very important. It can be if someone can have physical access to your machine, and intalls a rooted kernel. Because you don't have a kernel signed by Canonical.. the machine cannot check it is 100 % the kernel that Canonical did build.
For some people like CIA or NSA using Dell computers on Linux, having at all times a full secure boot chain is important. But usually, especially the NSA, they are good enough to have their own keys, the public part inserted into the EFI firmware, and sign their Grub2, kernels and modules. They don't need nor will use Canonical's key because it's safer when made "in house"
Please read this for more details :
https://wiki.ubuntu.com/UEFI/SecureBoot/Testing?action=show&redirect=SecurityTeam%2FSecureBoot
You can generate your own pair of keys. Insert the public part into the EFI.
And sign your Grub, kernel and kernel modules
But you will have to do this yourself, protect with utmost care your private part of key
And keep this up to date each time Grub, the kernel or modules are updated.
It requires more work from Canonical. So maybe they don't want to sign all the kernels.
They want the kernel in the pre-installed image signed for security.
And consider further updates being secure since GnuPG signatures are already used by apt.
Cannot answer for them. But Dell does not have this Canonical private key and they cannot sign the kernel. Only Canonical can do that. If you really want that SecureBoot chain to be kept at 100 %, you have to ask Canonical to keep the kernels they push out to be signed. Not Dell