Secureboot issues
-
@astrugatch
Please do not forget that after deactivating also the reactivation means further steps. And that with 500 devices within a week! -
Isn’t that what command and configure is for (if you’re a dell shop at least)?
-
@astrugatch said in Secureboot issues:
Isn’t that what command and configure is for (if you’re a dell shop at least)?
Yes, we use command and configure (CCTK) to set default bios settings. I started looking into building cctk into FOS Linux so those bios settings could be made via a post install script. I think that project fell off the table a while ago.
-
I would be very interested in that. Do you have a GIT for that, that I could look at?
-
@astrugatch It never made it to the repo. It was a skunkworks project I was working on. I just went and grabbed the centos version of cctk https://downloads.dell.com/FOLDER05519675M/1/command-configure-4.2.0-553.el7.x86_64.tar.gz to see if I could rebuild the test environment.
-
Hi all, i have secureboot working with ipxe (FOG) using a self-signed certificate and you do however need to enroll the keys but i have added an .efi program that you can run to automate all this from the pxe boot menu to ease this process.
i’ve been testing it for the last 12 months or so to see if there is any gotchas but none yet and over 80% of our estate have secureboot with ipxe working (7K devices) - only lenovo x1 carbons have been problematic but this appears to be due to poor bios and/or secureboot implementation.
this does mean you have to manage the certificates yourself going forward too as you are essentially taking ownership and provisioning the devices and applying your own PK which means you have to trust 3rd party CAs however the plus side there is no cost involved. i also don’t have assurances how to remotely distribute a renewed certificate when it expires but expiration is 10 years and there is going to be some work needed when microsoft CA expires in 2026.
on first attempt, i hadn’t included microsoft CA so windows os failed to load with untrusted error from secureboot… i loved the irony… i dont trust microsoft either
if anyone is interested i can write up instructions however you have to remember technically this is outside of FOG remit, so support on FOG forums will be extremely limited and unfortunately with 2 jobs i have very little time to spare either.
-
@lee-rowlett I am very interested; anyone else wants to see a writeup?
-
@lee-rowlett I would be very interested to see how this could be achieved. I have 1000 Lenovo devices and I would prefer to not have secure boot reconfigured on all machines…
-
@lee-rowlett Hi, Where is your “howto” ?
-
@lee-rowlett very interested, maybe i can do something if you can send me the information…
-
unfortunately i do not have time to write up in detail step by step instructions but this is how i’ve done it:
follow this brilliant guide:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htmlincluding “Securing Multiple Computers” section, once you’ve generated the “LockDown.efi”
copy LockDown.efi to ipxe folder on fog server (i’ve renamed mine to EnrollKeys.efi) then add the option to PXE Menu.
then sign your init, bzimage and any other bzimage version you may use with your new cert you’ve generated above - something like this:
cd /var/www/html/fog/service/ipxe mv bzImage bzImage-unsigned sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage bzImage-unsigned mv bzImage32 bzImage32-unsigned sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage32 bzImage32-unsigned mv bzImage41713m bzImage41713m-unsigned sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage41713m bzImage41713m-unsigned
just remember to re-sign any init/bzimage when upgrading kernel/fog.
so the process is when you get a new machine put secureboot into user/setup mode then boot to pxe and run “Enroll Keys” option on pxe menu which will set secureboot keys accordingly, the beauty of this is you will also only need to do this once on a machine and then you will have secureboot on working with fog, when you come to reimage that same machine secureboot will already be setup.
the only caveat i would say is i don’t know what the behaviour is going to be when the Microsoft UEFI CA expires in 2026 - as you’re now effectively managing your own secureboot keys - you will need to update and manage the CAs in the db. this would normally be managed by microsoft updates/OEMs i assume.
-