"Secure Boot" for Puppy Linux
The current grub2.03 in Puppy Linux does not work when "Secure Boot" is enabled.
Proposal for Puppy Linux to support "Secure Boot":
I have "borrowed" a signed "shim", "grub2" and "MokManager" from Debian Bookworm.
https://forum.puppylinux.com/viewtopic. ... 98#p131598
This takes care of all signing up until "grub2", so the computer will boot up to the "grub2" menu.
But selecting a menu entry will produce an error message since the Linux kernel is not "signed".
This same set of ".efi" files will "go all the way" if Secure Boot is disabled,
so it could be our default "grub2" install.
This leaves us with the task of signing our kernels and kernel modules, in some circumstances.
Fortunately the DKMS folk have a similar problem, i.e. having to "sign" any compiled module.
So there are some useful scripts around that generate and enroll a MOK, and use it for "signing" modules.
I have been able to put together some crude testing scripts to support this,
e.g "genMOK", "enrollMOK", "signKernel", and "signModulesDir".
Using these, I signed the latest 5.10.226 64bit kernel from woof-ce, and it's modules.
Used this kernel in a JammyPup32 install, and it booted and loaded it's modules with "Secure Boot" enabled.
https://www.mediafire.com/file/6scp8fho ... ar.gz/file
( It contains, 'modules-5.10.226.signed.sfs, 'vmlinuz-5.10.226.signed', and ' MOK.der')
The next step would be to provide some Puppy Linux releases that include a "signed" kernel, and the appropriate "public" key.
e.g. I could create a "Puppy Linux signer - gyrog" MOK and use this to "sign" the kernel when I produce a ".zip" release of a Puppy.
Similarly each publisher of a Puppy would have an option to publish a "signed" Puppy with the kernel "signed" with a MOK of their own making.
Issues:
The "sign-file" binary used in "signModulesDir" is usually supplied by the kbuild sfs in Puppy.
So if you are running a 64bit kernel in a 32bit Puppy, "sign-file" won't execute.
I had to run "signModulesDir" in a 64bit Puppy.
Since the MOK used for signing the kernel and modules, is not the one used for signing grub2,
the MokManager will not be automatically triggered if our signing MOK is not enrolled.
The signing MOK has to be enrolled via "mokutil" before booting the signed kernel.
Where to store the generated MOK?
I chose to use '/mnt/home/localMOK' so that it is easlily available to all my Puppies.
But if DKMS is to automatically sign modules, it may need to be elsewhere.
Where to store the MOK public key in a release?
Note on 32bit kernels:
"efibootmgr" and "mokutil" are 2 very useful utilities for working with uefi booting.
I've never managed to get them to work with 32bit kernels.
But using a 64bit 5.10.226 in my JammyPup32 enables them to work.
Also some available "grub2" binaries won't boot 32bit kernels, but again a 64bit kernel in a 32bit Puppy works.
All Puppies should be released with 64bit kernels.
Note on Secure Boot:
Secure boot utilises private/public key pairs.
Things "signed" with the "private" key, must be verified using the "public" key.
It depends on a "chain of trust".
The uefi/bios uses a "public" key already installed on your mother-board, to verify the "shim".
The "shim" then verifies the "Grub2" file using a "public" key contained within itself,
or using a MOK that has been enrolled on the machine.
"Grub2" then verifies the Linux kernel using a MOK that has been enrolled on the machine.
The Linux Kernel then verifies each module using a MOK, before it is loaded.
These MOK's do not have to be the same.