+- iPXE discussion forum (https://forum.ipxe.org)
+-- Forum: iPXE user forums (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: Secure booting linux / additional certificates (/showthread.php?tid=9133)
Secure booting linux / additional certificates - freaky - 2017-04-06 09:33
Hi,
we might want to look into the process of getting iPXE signed by Microsoft. We want to use it primarily to boot PXE boot Fedora in many environments. These will include BIOS, EFI w/o secure boot and EFI with secure boot.
We have the first 2 working just fine. It's the latter that's more complicated.
Secure boot with most distro's currently normally works with shim.efi which then loads grub. As this complicates the configuration a lot we'd like to prevent that.
From what I understood so far it's not possible currently to load additional certificates into iPXE for the secure boot validation, much like what shim does. Basically they get shim signed by Microsoft and shim has (and thus trusts) the certificate of RedHat or Ubuntu, etc. We would like to be able to include such certificates into iPXE so we can include the RedHat and preferably one of our own certificates into iPXE making it possible to directly boot code signed with those certificates from iPXE.
This would allow a single configuration with iPXE without additional requirements for shim/grub on secure boot platforms.
Could anyone comment on what would be required to get this working and if anyone knows the legal stuff comments on that would be welcome too. Not sure what the view on us requesting signing a binary with a RedHat certificate in it would be as we're not part of RedHat. There already are ways to boot binaries signed by RedHat certificates through their shim.efi so I doubt it would be a big no-no, but that's just from my technical perspective. I don't have any legal experience.
Thanks in advance.
RE: Secure booting linux / additional certificates - NiKiZe - 2017-04-06 20:45
iPXE itself does not have any certificates at all that is used to check signing, actually there is nothing at all in iPXE in regards to signing - this is all up to the firmware EFI implementation to handle when exec of efi files is called.
Solutions to this:
* Have MS sign iPXE then always load MS signed shim.efi from iPXE which in turn loads kernel - this shim should support loading and propagating efi fs and options, for example like this:
Code:
#!ipxe
initrd initramfs.img
initrd kernelx64efi
kernel shim.efi kernelx64efi initrd=initramfs.img init=/bin/bashmeaning that shim is only a wrapper.
* Make sure shim.efi implements and replaces the firmware exec interface and use load shim.efi -> ipxe.efi
Or it might even be possible to have MS signed ipxe.efi first which starts MS signed shim.efi which installs those interfaces and then returns to iPXE which can then boot efis signed by new certificates since the exec and signing check is now done by shim.efi instead.
as you can see this all requires some help from shim, maybe it already exists in the shim? Anyone have link to official sources of recent shim.efis ?
RE: Secure booting linux / additional certificates - freaky - 2017-04-07 10:54
Hi,
thanks for the re'. I'll try testing that Tuesday when I'm back at the office.
So far I've only tested by pointing DHCP 67 -> shim.efi and had both the grub and shim EFI's in the folder. shim automatically loaded grub, haven't tested yet what requests it does when the grub binary is missing. Grub was the first request.
Didn't have a config for grub yet, grub requested files in this order:
1) grub.cfg-01-52-54-00-a0-f4-1f (MAC prefixed with -01-)
2) grub.cfg-0AEAEA34 (not sure how this ID is generated)
3) grub.cfg-0AEAEA3
4) grub.cfg-0AEAEA
5) grub.cfg-0AEAE
6) grub.cfg-0AEA
7) grub.cfg-0AE
8) grub.cfg-0A
9) grub.cfg-0
10) grub.cfg
11) /EFI/fedora/grub.cfg-01-52-54-00-a0-f4-1f
12) /EFI/fedora/grub.cfg-0AEAEA34
13) /EFI/fedora/grub.cfg-0AEAEA3
14) /EFI/fedora/grub.cfg-0AEAEA
15) /EFI/fedora/grub.cfg-0AEAE
16) /EFI/fedora/grub.cfg-0AEA
17) /EFI/fedora/grub.cfg-0AE
18) /EFI/fedora/grub.cfg-0A
19) /EFI/fedora/grub.cfg-0
20) /EFI/fedora/grub.cfg
21) /EFI/fedora/x86_64-efi/command.lst
22) /EFI/fedora/x86_64-efi/fs.lst
23) /EFI/fedora/x86_64-efi/crypto.lst
24) /EFI/fedora/x86_64-efi/terminal.lst
It's the shim/grub supplied with Fedora 24 (used shim.efi not shim-fedora.efi, not sure what the difference is, would expect shim-fedora.efi to include additional certificates, but it's smaller than shim.efi).
Did eventually make a grub.cfg loading the Fedora kernel and this worked on a laptop with secureboot enabled. Was horribly slow though, the grub version provided unfortunately doesn't include the http module and including it would break the signature (pull from HTTP with iPXE). Besides, we'd like to use iPXE on all the environments so hoping your suggestion will indeed make shim load the kernel directly. End users will have to modify configurations for their own networks and we're stuck with BIOS, EFI-32 and EFI-64 bit environments. Haven't gotten feedback yet if the 32 bit EFI environments use secureboot because that could be troublesome as well as I only see a signed 64-bit grub. Not sure if the shim.efi is 32 or 64 bit but the end user stated the 32 bit EFI, whilst it has a 64 bit CPU, only loads 32 bit EFI code, which seems rather obvious (haven't had a chance to test it).
Preferably we'd use iPXE for all environments as it's much easier to configure and it's syntax it easier to understand for end-users.
Will have to discuss some stuff with our customer, but they might be willing to provide the sum required to get iPXE signed. We'll have to look into the best path to proceed.
When using just the included kernel modules we can go with the RedHat certificates, which have a shim signed by Microsoft. But we have machines with some issues that currently require the broadcom-wl package, which is compiled by the user and thus not signed by RedHat. Maybe we'll need our own certificates because of this or we must find a way for a kernel booted through secureboot to load unsigned modules or modules signed with another certificate. Haven't looked deeply enough at that yet. Might also require other proprietary kernel modules in the future.
Would prefer to be able to work with the default kernel provided by the distribution and not having to build our own kernel/modules and signing them every update by far. But if it can't be done otherwise we'll have to investigate our own certificate/signatures.
Thanks again and have a nice weekend.
RE: Secure booting linux / additional certificates - freaky - 2017-04-11 11:00
To answer your shim sources question: https://github.com/rhinstaller/shim
Just tested with passing the kernel as an initrd like you suggested, but it doesn't work. See iPXE downloading all 3 files, but then errors show up of an image not being found. There's 2 HTTP requests for grubx64.efi going out at that point. The errors talk about a TFTP image though. shim.efi seems to be hardcoded to load grubx64.efi unfortunately.
Used iPXE config:
:gototagname
initrd http://10.234.234.51/xxxx/vmlinuz0
initrd http://10.234.234.51/xxxx/initrd0.img
kernel http://10.234.234.51/shim.efi vmlinuz0 rootflags=loop initrd=initrd0.img root=live:/somefilename.iso rootfstype=auto ro rd.live.image quiet rd.live.ram quiet rhgb rhgb rd.luks=0 rd.md=0 rd.dm=0
boot
Onscreen output:
http://10.234.234.51/xxxx/vmlinuz0... ok
http://10.234.234.51/xxxx/initrd0.img... ok
http://10.234.234.51/shim.efi... ok
Fetching Netboot Image
Unable to fetch TFTP image: Not Found
Fetching Netboot Image
Unable to fetch TFTP image: Not Found
Could not boot: Error 0x7f04828e (http://ipxe.org/7f04828e)
Could not boot image: Error 0x7f0f828e (http://ipxe.org/7f04828e)
No more network devices
Press Ctrl-B for the iPXE command line...
RE: Secure booting linux / additional certificates - NiKiZe - 2017-04-11 19:49
Thanks for the sources!
Didn't really propose that it should work out of box, my proposals was both how shim.efi could be made to work with ipxe
The issue here is that shim goes to netboot mode when it instead should read the input from it's commandline
if shim is hardcoded to use grubx64.efi then it might be possible to use
initrd -n grubx64.efi http://10.234.234.51/xxxx/vmlinuz0
which forces the name in efifs to be grubx64.efi, but even so it is unlikely to work since netboot seems to be used, and also the cmdline itself i unlikely to be past on...
Maybe it is possible to use ifclose net0 before boot which might prevent shim to do netboot - but again cmdline probably won't be passed on anyway.