"Secure Boot" for Puppy Linux

[gyrog]

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.

[Clarity]

@peebee @dimkr @wiak @rockedge @shinobar

Could all of the future work be done using GRUB2 v2.12. Thus development and members helping could focus on resolving and advising on this version?

We all know that there are multiples of GRUB2 versions. Problem resolution/discussion could be minimize to this long standing version that accomodates old and new PCs. (I saw, today, someone posting about GRUB2 v2.03)

If this make sense, we'll see the movement in future forum PUPs and distros.

[gyrog]

Could all of the future work be done using GRUB2 v2.12. Thus development and members helping could focus on resolving and advising on this version?

In my testing I tried grub2.12 from Debian Trixie, and I could find no i386 binaries.
It also failed to boot 32bit kernels.

The actual version of grub2 is not vital to what I'm trying to do here.
The important thing is, Puppy folk accepting this as an acceptable way of handling MOK's, and starting to produce "signed" kernels, and Puppies that include signed kernels and signed grub2 binaries, and hence support "Secure Boot".
A newer version of grub2 could easily be utilised when it is mature enough, and Puppy is far enopugh down the road of abandoning 32bit Puppies.

Normally a Linux distributioin would have a single signing key, used for all releases.
But such an approach would not easily fit the distributed Puppy environment.
So, we could have a small number of folk releasing "signed" Puppies using their onw MOK, and/or individuals who want to have Puppies that support "Secure Boot" doing their own "signing" of "unsigned" Puppy releases using the provided utilities.

The short term goal is to improve the utilities to make it easy to do.

[gyrog]

I have uploaded https://www.mediafire.com/file/3mm55t18 ... ar.gz/file.
It contains 5 utilities and an include file.
Simply extract the tar file somewhere, preferably a directory in the "PATH", e.g. "$HOME/my-applications/bin".

Code: Select all

tar xf signKernelUtils-01.tar.gz -C $HOME/my-applications/bin

getMOKdir
This file establishes the directory containing the local MOK.
It is not a utility, it is included by the utilities when needed.
This is the only file that needs to change if the local MOK location is changed.

genMOK
Generates a local MOK, without any pass phrase on it's private key.
This simplifies the utilities that use it.
"genMOK" takes a single parameter, the string to be used as the "CN=" information in the key.
e.g. "Puppy Linux signer - myname"

enrollMOK
Executes "mokutil" to enroll the generated local MOK.
"mokutil" asks for a one time password, which will be needed by the "MokManager" after a reboot, to authorise the change.
This 2 step process is normal for "mokutil".

signKernel
Signs the specified kernel with the local MOK using "sbsign".
The original kernel will be moved to ".unsigned" and the signed kernel will replace the oroginal.
It takes 1 parameter, the full path of a kernel file, e.g. '/pups/upupjj32/vmlinuz'.

signModulesDir
Signs all the kernel modules found within the specified directory using "sign-file".
Takes 1 parameter, the full path to a directory containing kerel modules.
(Probably not used directly in Puppy.)

signModulesSfs
Signs all the kernel modules in an sfs file, using "signModulesDir".
It extracts the contents of the sfs file into a direcory and executes "signModulesDir" against this directory.
"mksquashfs" is then run to create a new sfs file as ".signed.sfs" instead of ".sfs".
The original sfs is then moved to ".unsigned.sfs" instead of ".sfs" and the signed sfs replaces the original.
It expects the input sfs to be a "zdrv".
Takes 1 parameter, the full path to an appropriate sfs file.
(Probably the usual way of signing kernel modules in Puppy.)

Notes
These utilities still need a fair bit of polish, but they are a start.

Both "signKernel" and "signModulesSfs" could easily be modified to produce ".signed" versions and leave the original files alone.

[gyrog]

Just in case nobody has noticed it:
If you want too try this stuff, yout need the grub2-efi binaries from https://www.mediafire.com/file/hvpptosb ... ar.gz/file as announced in https://forum.puppylinux.com/viewtopic. ... 98#p131598.

[Clarity]

Thanks @gyrog for all the effort to signal a path forward and the utilities provided for KEY Management.

A newer version of grub2 could easily be utilised when it is mature enough, and Puppy is far enopugh down the road of abandoning 32bit Puppies.

YES, PUPPY Linux has addressed the old iron for many years. Next year signals 2 decades since 64bit PCs became publicly available. Linux and Puppy has been available for the multitude of PCs ever since.'

Like many other Linux distros, there will be a time when the limited development resources be turned to focusing of 64bit only to reduce the workload in production as well as maintenance. (It takes time, analysis, and effort to address multiple differing platforms. With ARMs, this necessary effort extends.)

The old PUPs and linux distros I have, still boot on both 32/64 iron. So this fact does leave functioning solutions for the reducing 32bit-only users still around after all these years.

Thanks @gyrog AGAIN!

[gyrog]

@Clarity, you are welcome.

[gyrog]

The first signed Puppy Linux https://forum.puppylinux.com/viewtopic. ... 90#p131690

[rockedge]

@gyrog I've been thinking about how to do this for awhile now. Excellent progress on this development and seeing it actually done on a Puppy Linux is very encouraing.

Well done Grasshopper.

(old TV show "Kung Fu" reference for the youngsters)

[gyrog]

There is an issue with using a pre-signed 'grubx64.efi':

1) We have a "signed" Puppy containing a pre-signed 'grubx64.efi', on a USB stick,
and try to boot it on a Windows only machine with "Secure Boot" enabled.
The "shim" will be able to verify 'grubx64.efi' so the boot will proceed to the grub menu, but selecting a Puppy will fail because The MOK for the kernel is not enrolled.
The only way out of this "dead-end" would be to disable "Secure Boot", boot Puppy and run 'mokutil' to enroll the MOK, reboot and re-enable "Secure Boot".

2) We have a "signed" Puppy containing a 'grubx64.efi' signed with the same MOK as the Kernel, on a USB stick,
and try to boot it on a Windows only machine with "Secure Boot" enabled.
The "shim" will not be able to verify 'grubx64.efi' so it will call the "Mok Manager" to allow you to enroll a MOK from disk.
After enrolling the supplied MOK from disk, the boot will proceed, and Puppy will boot.
(No need to disable "Secure Boot".)

Assuming that 2) is the preferred outcome, we should store Grub2 with a pre-signed 'bootx64.efi', and 'mmx64.efi',
but an unsigned 'grubx64.efi'.
When installing a Puppy in a "signed" environment, we sign the 'grubx64.efi', 'vmlinuz' and the kernel modules in the 'zdrv...sfs' with the same MOK.
All of this is quite doable, even with the basic scripts currently available.

Using this approach, we can extend the concept of "Secure Boot" to include "Anything that I approve" as well as "Anything someone else approves".
Each user who wants to run with "Secure Boot" enabled, would generate their own MOK, enroll it, and sign the local 'grubx64.efi' with it.
Then to "approve" a Linux, they would need to sign the kernel and it's modules with their own MOK.
Installer utilities could automatically do this if a local MOK is found.
(Although "signing" the large number of kernel modules in a 'zdrv...sfs' takes a little while.)

If a local MOK is found:

1) 'FrugalPup->Puppy' could "sign" the kernel and it's modules of the Puppy being installed, provided the 'vmlinuz' file is "unsigned".
'FrugalPup->Boot' could "sign" the 'grubx64.efi' binary, if it is installing grub2.

2) 'StickPup' could sign the 'grubx64.efi', 'vmlinuz' and the kernel modules in the 'zdrv....sfs', being installed.

So the Puppy community would continue to produce unsigned kernels and Puppies.
Except for a small number of "starter" Puppies that are signed with the publishers MOK.
But once the "starter" Puppy is running a local MOK could be generated, etc...
Then the "starter" Puppy could be deleted, and it's MOK deleted from the computer.
(My "ziprelease" Puppies could become one example of a 'starter' Puppy.)

The bulk of the extra work ends up with the users who want to enable "Secure Boot".
No users computer ends up with lots of MOK's.

The alternatives are to have a single Puppy MOK, which implies a single signing person,
or
every Puppy is "signed' with it's own MOK, or each Puppy publisher "signs" with their own MOK, user ends up with multiple MOK's.

[gyrog]

I have uploaded https://www.mediafire.com/file/v688lnef ... ar.gz/file.
Simply extract the tar file into a directory beside your other AppDir's.
Then open this directory and run the 'setup' script.

The location of the MOK files has been changed to encourage the storing on a "removable" device, e.g. a USB stick that is normally not connected to the computer.
Then, using the MOK private key requires physical access to the computer and the appropriate USB stick.

"getMOKdir" is now a utility that is run by other scripts, rather than being an include file.

getMOKdir
This script now searches for a mounted FAT32 partition that contains a "/PLK" directory.
If found, this becomes the source directory for MOK files.
Otherwise the MOK files are not found, and the callng utilities will error exit.

genMOK
Now error exits if "getMOKdir" does not find the MOK directory.

mkMOKdir
A new utility to create a "/PLK" directory on a specified mounted FAT32 partition.
It's best to run this before using "genMOK".
Takes a single parameter, which is a partition name, e.g. "sdd1".

signBinary
Used to be called "signKernel".
The name change recognises that it can be used to sign either a "grubx64.efi" as well as a "vmlinuz" file.

setup
Creates symbolic links to the MOK scripts in "$HOME/my-applications/bin".

unset
Deletes the relevent symbolic links in "$HOME/my-applications/bin", if they exist.

[gyrog]

@rockedge, thanks.
And you are welcome.

[wiak]

No need ever I feel to give up on any 32bit dev products as long as some upstream distro repos , such as Void Linux, continue to support it. These don't really water down overall dev efforts since just really involves different architecturechoice for component repos.

Secure Boot will likely always be a problem though. It is great that gyrog has investigated and implemented how to do it, which is a great deal of commendable effort on his or her part. However, the majority of the general public will never attempt the enrollment of any MOK no matter how many clever scripts are provided to them. Unfortunately I don't myself see any way out of that main problem.

Great work by gyrog nevertheless, which the more technical among us all will sometimes find very useful.

For others, the way ahead, whether for those who boot into Linux or those who boot into Windows is to provide strong support for use of our distros in virtual machines, for which I assume the secure boot issue disappears?

[Jasper]

@gyrog

Would this toolkit be useful?

viewtopic.php?p=129164#p129164

[gyrog]

@wiak, you seem to be asking, Why bother?

While thinking upon the fact that a while ago Puppies installed by FrugalPup would boot with "Secure Boot" enabled, but now don't,
I eventually became intrigued by the question of could we implement the "normal" "Secure Boot" thing,
i.e. use signed kernels, and retain the freedom we currently have with Puppy Linux??

This project is my "proof of concept" that it can be done, although with some pain.
Will anyone consider that support for "Secure Boot" is worth the pain??
That's for other's to decide by "voting with their feet".

So I will complete the project to the point where I consider it to be "usable".
This means the infrastructure will be available if anyone wants to use it.

Gains for Puppy:

1) The immediate gain is the availability of an updated grub2 to 2.06,
with a probable upgrade to 2.12, once the dust settles.
(I think the relevent files can be obtained from "bookworm-backports".)

2) Users will have a choice to install "unsigned" Puppies as "signed" Puppies and boot them with "Secure Boot" enabled.
Users will also have a choice to "sign" their curently installed "unsigned" Puppies.
Provided they are prepared to accept the MOK pain, once per computer.
If they reject the MOK pain, everything will remain as now.

Downsides for Puppy:

It might be nice if a very small number of folk produced "starter" releases of Puppy occasionally.
These would include a signed grub...efi, kernel and modules, and the producers MOK public key, so they could boot on a Windows only computer with "Secure Boot" enabled.
My "ziprelease" Puppies could be a target for this treatment.

Frugal install directories could become littered with 'vmlinuz.unsigned' and 'zdrv...unsigned.sfs' files.

[gyrog]

Would this toolkit be useful?
viewtopic.php?p=129164#p129164

Maybe;
The utilities used by the current scripts are:
efibootmgr
mokutil
openssl
sbsign
sign-file

"sbctl" maybe be able to replace some or all of these, it could be worth a look.
But if it does, the current scrips would need to be modified to use this different utillity.

The following facilities are needed:
create a MOK
check if a MOK is enrolled
enroll a MOK
check if a binary is signed
sign a binary
sign a kernel module
register a specified ".efi" file in a specified directory and partition, to the uefi/bios as a "boot" option.

Edit: Thanks for the suggestion, but it looks like it's designed for replacing all the "Secure Boot" keys rather than managing a MOK.
A slightly different environment than what I'm looking at.

[wiak]

@wiak, you seem to be asking, Why bother?

No, I think it is very much worth the difficult effort. I often wanted to investigate and try and understand much of the same, but for some time now I don't seem to have so much energy or focus as I had five and more years ago. May be old age creeping up, but I like to think it is more to do with tons of other issues in my life generally that I didn't have five years ago, which refuse to give me much peace.

Overall I think the work is essential and will likely work for a lot of people here in some way or other in the end. But... when it comes to the computer-using masses, Microsoft has control over them because MS will work without MOK related effort that that general public will with certainty never ever master (or risk). I don't see them as important actually - better really they just use MS or MAC. Mainstream Linux distros are the only ones that might work almost out of the box. Special featured clever little distros such as we make here are for us more adventurous lot to enjoy and celebrate. Might sound elitist, but really it is just a point of difference in overall interest.

So, no the work is important and even near essential, but attracting the 'nubes' out of windows here was never a great idea or likely have mass-following anyway, and less so now...

Better I feel to accept that we are all a special EDIT: let's say 'type of technically interested group of people"...here and what we need to attract is more like us, and I refer to enthusiastic adventurers, not at all guru nerd types. All sorts of intelligent people, because open-minds full of curiousity and intelligence is what this fun hobby is about for all of us I think.

[gyrog]

@wiak, thanks for the clarification.
And I agree that a MOK solution such as this is unlikely to be attractive to the "masses".
Unfortunately a seamless solution is out of our league.

The likes of Debian get Microsoft to "sign" a shim that contains a debian public key.
Then the grub2 binary can be signed by the Debian private key and so verified with this embedded public key.
And similarly, the kernel and it's modules.
So it all works seamlessly without the MOK manager ever rising it's "ugly head".

But we do not have access to Debian's private key, to "sign" our kernels,
or have the resources to get Microsoft to sign a shim that includes a Puppy public key.
So we are left with having to enroll a MOK that comes into play either at the grub2 level or the kernel level.

I am attracted to the idea, that using this approach, I can control what I "sign" and hence what can run on my computer, under "Secure Boot". (Although it won't stop OS's that have been approved by others, from running.)

[gyrog]

I have uploaded 'signKernelUtils-03.tar.gz' to https://www.mediafire.com/folder/dtvy7d42uot5q/boot.
Simply extract the tar file into a directory beside your other AppDir's.
Then open this directory and run the 'setup' script.

Most significant change is a 'help.html' file is included with a brief help for each of the scripts.
('setup' does not do anything about the 'help.html' file.)

Also minor changes of some names:
The "/PLK" directory on the "PLK" labeled partition is now the "/MOK" directory on the "MOK" labeled partition.
The MOK files are now called "local.<something>" instead of "MOK.<something>"

I have also uploaded 'recipie.txt' to https://www.mediafire.com/folder/dtvy7d42uot5q/boot.
This contains a brief description of how to "borrow" the relevent grun2.06 files from Debian.

I have also uploaded 'grub2-efi-bin.tar.xz', 'grub2-efi-font.tar.xz', and 'grub2-mbr.tar.xz' to https://www.mediafire.com/folder/dtvy7d42uot5q/boot.
These are the files that contain grub2.06 for inclusion in the next FrugalPup.

grub2-efi-bin.tar.xz
Contains just the ".efi" binaries.
If '/EFI/Puppy' exists extract 'grub2-efi-bin.tar.xz' into it.
Otherwise extract 'grub2-efi-bin.tar.xz' into '/EFI/boot'.

grub2-efi-font.tar.xz
Contains the 'DejaVuSansMono18.pf2' font and a few grub2 ancillary files, in their directories.
It can be extracted into the root of the FAT32 boot partition.

grub2-mbr.tar.xz
Contains the mbr binaries for grub2.06, in their directories.
It can be extracted into the root of the FAT32 boot partition.

To start using this stuff:

Begin with "Secure Boot" disabled.

1) You need to be running a Puppy with working copies of the following utilities:
efibootmgr
mokutil
openssl
sbsign
sbverify
sign-file

2) You need to be using the grub2.06 binaries.
Extract grub2-efi-bin.tar.xz into '/EFI/boot', or '/EFI/Puppy' if it exists.
Reboot, to establish that these grub2 binaries work.

3) Install the CLI MOK utilities from 'signKernelUtils-03.tar.gz'.

4) Make sure you have a USB stick that can boot a Puppy on your current machine.

With the current scripts, setting up a MOK requires;
1) Choosing a partition to contain the MOK, and running 'mkMOKdir' with the name of the partition as a parameter.
2) Choosing a string to describe the MOK, and running 'genMOK' with this string as a parameter.
3) Run 'enrollMOK', providing a new single use password twice.
4) If your local MOK partition is not usually mounted, umount it.
5) Reboot.
6) The Mok Manager should run to actually enroll the key, though you will have to provide the password from step 3)

Getting ready to enable "Secure Boot":

Ensure that you are running a Puppy with the full set of utilities..

1) Make sure your local MOK partition is mounted.

2) Run 'signBinary' with the full path of your 'grubx64.efi' as a parameter.

3) "Sign" at least 1 installed Puppy:

It's not a good idea to "sign" a mounted 'zdrv...sfs'.
so either "sign" a Puppy other than the one you are running,
or
ensure that the 'zdrv...sfs' of your running Puppy was copied to RAM during the boot process.
or
obtain a new kernel for your Puppy, "sign" it, and then change kernels.

Run 'signBinary' with the full path of your 'vmlinuz' as the parameter,
if 'signBinary' did not report that your 'vmlinuz' was already signed,
run 'signModulesSfs' with the full path of your 'zdrv...sfs' as a parameter.

Note: 'signModulesSfs' usually takes a while, since a kernel typically has a few thousand modules.

3) Reboot and enter the uefi/bios setup, then enable "Secure Boot".
(On my current mother-board, this means changing "Secure Boot" from "Other OS" to "Windows UEFI mode".)
Exit, saving changes and reset.

4) The boot should proceed to the grub menu, although it may look strange.
Selecting the Puppy you "signed" should boot.
Selecting an "unsigned" Puppy should result in a failed kernel load.
You could now "sign" other installed Puppies using 'signBinary' and 'signModulesSfs'.

The grub menu may look strange beacuse your 'grub.cfg' loads an external font.
With "Secure Boot" enabled, this is not allowed, you can only load an internal font.
This can be improved by using code like the following, in your 'grub.cfg':

Code: Select all

  if [ -n "$shim_lock" ]; then
    loadfont (memdisk)/fonts/unicode.pf2
  else
    loadfont /boot/grub/fonts/DejaVuSansMono18.pf2
  fi

A byproduct of code like this, is the grub menu provides visual feedback as to whether "Secure Boot" is enabled.

5) Of course you can always return things to normal by disabling "Secure Boot" in your uefi/bios setup.

How would FrugalPup handle this stuff:

In the "Puppy" facility:
If, and only if, it finds a local MOK present and the 'vmlinuz' being installed is "unsigned",
it will automatically "sign" the 'vmlinuz' and the modules in the 'zdrv...sfs' in the install directory,
with the local MOK, without any extra input from the user.

In the "Boot" facility:
If it is installing grub2,
it will use the ".efi" binary files from 'grub2-efi-bin.tar.xz',
if, and only if, it finds a local MOK, and the 'grub...efi' being installed is "unsigned",
it will automatically "sign" the 'grub...efi' file with the local MOK, without any extra input from the user.
If it is generating a 'grub.cfg' file, it will include the font code shown above.

So, once you have setup your local MOK,
it will just as easy to do a frugal install of a Puppy as "signed", as it would be for "unsigned", using FrugalPup.
And there is no reason why future versions of other installers could not work in a similar way.

[gyrog]

If you are looking for the 'sign-file' utility, it's usually in the 'kbuild...sfs'.
If your Puppy doesn't have a 'kbuild...sfs', then look in your 'kernel_sources' as '/usr/src/linux/scripts/sign-file'.

[gyrog]

Example code:

There is now a FrugalPup that implements this stuff, viewtopic.php?p=132128#p132128

The following code will only "sign" things if the 'signKernelUtils' have been extracted and 'setup' executed.
And if a MOK partition, containing a private local MOK, is mounted at the time the code is executed.

'signBinary' fails,
if the binary file does not exist,
or the binary file is already signed,
or a local MOK can not be found.

FrugalPup code for signed grub:

Code: Select all

type signBinary >/dev/null 2>&1
if [ $? -eq 0 ]; then
	for  oneGrub in grubia32.efi grubx64.efi; do
		[ -e "$BIN_DEST/$oneGrub" ] && signBinary "$BIN_DEST/$oneGrub" >/dev/null 2>&1
		[ -e "${BIN_DEST}/${oneGrub}.unsigned" ] && rm "${BIN_DEST}/${oneGrub}.unsigned"
	done
fi

FrugalPup code for signed kernel:

Code: Select all

type signBinary >/dev/null 2>&1
if [ $? -eq 0 ]; then
	signBinary "$DEST_DIR/vmlinuz" >/dev/null 2>&1
	if [ $? -eq 0 ]; then
		DEST_Z="$(find $DEST_DIR -mindepth 1 -maxdepth 1 -name 'zdrv_*.sfs')"
		signModulesSfs -q "$DEST_Z" >/dev/null 2>&1
	fi
fi

[gyrog]

The code for signed grub, omitted to copy the ".cer" file.
The patched FrugalPup code:

Code: Select all

type signBinary >/dev/null 2>&1
if [ $? -eq 0 ]; then
	for  oneGrub in grubia32.efi grubx64.efi; do
		[ -e "$BIN_DEST/$oneGrub" ] && signBinary "$BIN_DEST/$oneGrub" >/dev/null 2>&1
		[ -e "${BIN_DEST}/${oneGrub}.unsigned" ] && rm "${BIN_DEST}/${oneGrub}.unsigned"
	done
	type getMOKdir >/dev/null 2>&1
	if [ $? -eq 0 ]; then
		mokDIR="$(getMOKdir 2>/dev/null)"
		[ "$mokDIR" ] && [ -e "$mokDIR/local.cer" ] && cp -af "$mokDIR/local.cer" "$DEST_MP/puppyMOK.cer"
	fi
fi

Edit:
With the latest 'signKernelUtils' it is appropriate to append "2>/dev/null" to the 'getMOKdir' call, (redirect "stderr").

[gyrog]

I have uploaded 'signKernelUtils-04.tar.gz' to https://www.mediafire.com/folder/dtvy7d42uot5q/boot.
Simply extract the tar file into a directory beside your other AppDir's.
Then open this directory and run the 'setup' script.

The error message reporting has been significantly improved.
All the utilities take advantage of 'stderr' to propogate error messages from lower level scripts to calling scripts.

The algorithm within getMOKdir has changed slightly,
If the system contains a partition with a "MOK" LABEL, it will stick with trying to use it.
It will only search the FAT32 partitions if no "MOK" LABELed partition exists.

If no parameter is provided to mkMOKdir, it will use a partition with a LABEL of "MOK" if one can be found.

Recommendation:
Insert a small empty USB stick, (the keys only use about 25KiB).
Run 'fatlabel' to set it's partition LABEL to "MOK".
Mount this partition.
Run 'mkMOKdir' without any parameter.
Run 'genMOK" to create you local MOK.
Run 'enrollMOK' and reboot.

If this USB stick is mounted, the MOK utilities can be used to sign things,
if it is not inserted, they can not.

And software like FrugalPup v42 will setup "signed" stuff if this USB stick is mounted,
and "unsigned" stuff if this USB stick is not inserted.

[ozsouth]

@gyrog -

some available "grub2" binaries won't boot 32bit kernels

This may be useless to you, but it's what I use to boot 64 & 32 bit puppies.
Zip contains efi bootloader, layout png & sample grub.cfg. Use at own risk.

(link deleted)

[gyrog]

@ozsouth,
Thanks for the suggestion.

Could you please tell me what version of grub2 it is, and where it comes from?

Interesting layout.
In my testing, I have found no evidence of a need to store the vmlinuz and initrd.gz files in the ESP, or even on the same device.

[gyrog]

Where are we at with "Secure Boot" support?

We have working scripts to:

Sign binaries, 'grub....efi' or 'vmlinuz'.
Sign the kernel module files in a directory or a ".sfs" file.
Generate, store, and enroll a MOK.

Basically, we can do it.

The question is how we want to manage MOK's?

Options:

1) Have a single Puppy MOK, which implies a single Puppy signer.
Many Puppy releases are signed.

2) Every Puppy publisher has their own MOK,
All Puppy releases are signed.

3) Users who want to run with "Secure Boot" enabled, have their own local MOK,
Puppies, (and possibly other things) get signed during the install process.
Normal Puppy releases are not signed.

Notes:

Only option 1) restricts a particular MOK to Puppy.

There probably should be some "signed" Puppies released, to support first boot on a "Secure Boot" enabled computer.

Signing things on a computer with frugal installs, or full installs, is not difficult,
Signing things within a container (e.g. an ISO file) is not quite so simple.
The files have to be extracted, signed, and a new container created.
Although it should be possible to write a script that accepts an unsigned ISO and produces a signed ISO.
So the signer would not necessarily have to be the Puppy publisher.
And Woof-CE would not necessarily have to be able to produce signed ISO files.

"Secure Boot" being enabled, does not affect the loacation of the signed kernel and it's modules.
My "boot" device is an SSD, I have sucessfully booted a signed Puppy, frugally installed wholly on my HD, with "Secure Boot" enabled.
(I have come across the idea that signed kernels have to reside in the "boot" partition.)

Having "signed" grub2, kernels, and kernel modules, makes no difference if "Secure Boot" is disabled.
Although they take up just a little more disk space.

[mistfire]

I have uploaded 'signKernelUtils-04.tar.gz' to https://www.mediafire.com/folder/dtvy7d42uot5q/boot.

I saw grub efi files on that folder. Is it signed already and also able to search for grub.cfg file?

[gyrog]

I saw grub efi files on that folder. Is it signed already and also able to search for grub.cfg file?

The grub efi files are not signed.
I am not aware of any facility to search for a grub.cfg file.
But I tend to litter the sub-directories of the ESP with grub.cfg files like this:

Code: Select all

# The real config file for grub is /grub.cfg
source /grub.cfg

The end result is that any grub2 binary should find the real /grub.cfg. no matter where it looks.

[gyrog]

This may be useless to you, but it's what I use to boot 64 & 32 bit puppies.
Zip contains efi bootloader, layout png & sample grub.cfg. Use at own risk.

https://www.mediafire.com/file/vvr3w2as ... 2.zip/file

Issue 1, the grubx64.efi is signed by a MOK whose private key I have no access to.
Issue 2, there is no grubia32.efi file.
I own a laptop that will only boot grub2 with 32bit efi files.

[ozsouth]

@gyrog - Here are the old forum links which have source links (32bit didn't work for me):

64bit: https://oldforum.puppylinux.com/viewtop ... 27#p975827

32bit: https://oldforum.puppylinux.com/viewtop ... 81#p957281

That 'layout' is the only way it works for me. After 5 downloads, I've deleted it, as I'm
not recommending this for anyone else, just posted as what I use. It may be insecure.