Talk:Unified Extensible Firmware Interface/Secure Boot
Enroll hash file name
I am a bit confused regarding the following lines:
* In the HashTool main menu, select Enroll Hash, choose \loader.efi and confirm with Yes. Again, select Enroll Hash and archiso to enter the archiso directory, then select vmlinuz-efi and confirm with Yes. Then choose Exit to return to the boot device selection menu.
- In the boot device selection menu choose
Arch Linux archiso x86_64 UEFI CD
There is no file vmlinuz-efi in the said directory, there is only efiboot.img. Then, the USB stick actually wants to boot from arch/boot/x86_64/vmlinuz. I am not sure which file I actually had to enroll, it was either archiso.img in that directory or the vmlinuz kernel image. In either case the instruction is not accurate. --Johannes Rohr (talk) 09:03, 5 February 2015 (UTC)
- Indeed the instructions are not accurate, and are only meant as an outline. The thing is that their accuracy depends on the approach chosen. For example, the article suggests, among other approaches, to disable secure boot altogether. I think one is expected to integrate the outline in booting archiso with one of the approaches suggested by the rest of the article. For example, the Set up PreLoader section explicitly states the usefulness of
PreLoader.efiandHashTool.efiin efitools is limited. But it also suggest how to get along withPreLoader.efiandHashTool.efifrom preloader-signedAUR or to download them manually without using the AUR. Regid (talk) 02:05, 18 December 2018 (UTC)
- The comment you're replying to is from a time when the Archiso supported Secure Boot. -- nl6720 (talk) 09:34, 18 December 2018 (UTC)
- Why, and when, support for secure boot removed from Archiso?
- I find the article confusing. Most of it assumes users are able to install software on the machine, and copy files from anyplace to anywhere on the HD. As if they have a running archlinux installation, and only need to convert the boot process into secure boot. But installation is different. I think the booting archiso section should be moved to the section that is prior to see also; emphasize that there is a need to create files and than place them on the EFI system partition; point to archiso and Remastering the Install ISO; and reworked in general.
- Regid (talk) 10:59, 18 December 2018 (UTC)
- The comment you're replying to is from a time when the Archiso supported Secure Boot. -- nl6720 (talk) 09:34, 18 December 2018 (UTC)
- As it says in Secure Boot#Booting archiso, Secure Boot support was removed starting with
archlinux-2016.06.01-dual.iso. It happened because an Arch developer replaced[1][2] the prebootloader package with the efitools package. Apparently it happened because both containPreLoader.efiandHashTool.efi. The little detail that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[3]. -- nl6720 (talk) 11:15, 18 December 2018 (UTC)
- As it says in Secure Boot#Booting archiso, Secure Boot support was removed starting with
- Regarding your "2." point. The simple method is to disable Secure Boot, install Arch Linux, setup and enable Secure Boot. The Template:Out of date is there because you can't boot the official install media with Secure Boot enabled. If you want to add instructions on remastering Archiso with Secure Boot support, go ahead. -- nl6720 (talk) 11:18, 18 December 2018 (UTC)
- +1 to the simple method regarding section organization. @Regid: I get what you meant about the template and instruction-flow. Still, I find the current organization even more confusing. Now, the first link goes to Secure Boot#Put firmware in "Setup Mode", jumping over all the steps that must be understood/done. The last thing someone must do is to remove a platform key from the UEFI before there is an installable ISO. -- Indigo (talk) 20:31, 18 December 2018 (UTC)
- Thanks, IMO it's better like this for now. Something the article still needs is a little more intro how to proceed for either of the major sections. My suggestion for it is to do it in the [4] (better idea? change it). I realize that "Change the status" is not an ideal subsection title, but it should give an idea what's missing in my view. An alternative would be to put it into the article intro with 2-3 sentences. --Indigo (talk) 19:15, 20 December 2018 (UTC)
shim
I couldn't add anything to MoKList on my real PC, but everything worked in qemu; it could use more testing. The instructions should theoretically work for rEFInd and GRUB. AFAIK systemd-boot doesn't support shim and trying to launch SYSLINUX resulted in "System is compromised. halting.".
The instruction are for a generic bootloader because I have no interest in installing GRUB, and adding instructions for rEFInd would be pointless since rEFInd has a really simple setup for shim refind-install --shim /usr/share/shim-signed/shim.efi for hash only and refind-install --shim /usr/share/shim-signed/shim.efi --localkeys for hash and keys. If anyone is willing to rewrite the instructions to use GRUB as the example bootloader, please do. -- nl6720 (talk) 13:02, 7 December 2016 (UTC)
- A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. UBF6 (talk) 14:40, 8 November 2018 (UTC)
add section explaining the signing of other EFI utilities, or general troubleshooting section
I'd like to propose adding a section that explains the signing of other EFI utilities such as those detailed on https://wiki.archlinux.org/index.php/REFInd#Tools
In particular I've just recently resolved an issue which I'm guessing is specific to my motherboard (ASrock Z77 Extreme4) that I'd like to add some troubleshooting info on. Specifically the gdisk_x64.efi image is shipped signed with the author's key, and apparently my bios only looks at the first key signature of a given EFI app. By removing the author's signature with sbattach --remove gdisk_x64.efi I was finally able to get it to run with Secure Boot enabled.
Or maybe this would be better added to a general troubleshooting section? I haven't tested it but I bet if I first signed *any* EFI app with some key that isn't enrolled on my system, and then added my own, I'd have the same issue.
--AaronM_Cloudtek (talk) 05:31, 25 March 2019 (UTC)
- I think perhaps this could be included in a general section about signing binaries. Whether you use shim, preloader, or your own keys, you still have to sign the binaries. The only real difference is where the certificate is stored (db, or MOKList).
- Soroshi (talk) 20:32, 24 December 2019 (UTC)
Booting with own keys but without Microsoft's keys
I was unable to boot my computer (black screen before the POST) after removing Microsoft's keys from firmware and enabling Secure boot. This was because of my graphic card, as explained in Rod Smith's article:
- Some plug-in cards have firmware that's signed by Microsoft's keys. Such a card will not work (at least, not from the firmware) if you enable Secure Boot without the matching public key. (The card should still work once you've booted an OS. The biggest concern is for cards that must work in a pre-boot environment, such as a video card or for PXE-booting a network card.) You can add Microsoft's keys back to the environment to make such cards work, but this eliminates the advantages of not having those keys, if that's a significant factor for you.
I was able to fix it by extracting the UEFI driver (GOP) from the video BIOS of my card, signing it with my own key and re-flashing the VBIOS. It might not be possible with every cards. Anyway, it should be specified that removing Microsoft's keys can render the boot impossible, independently of the dual booting with Windows.
—This unsigned comment is by Palimpseste (talk) 07:09, 10 December 2019. Please sign your posts with ~~~~!
- Having gone through this process myself recently, I am considering re-writing this section to be much clearer. I am wondering what general skill level should be targeted with this section. It is certainly not a simple procedure, but it's not that complicated either. My changes would be based on Rod Smith's guide, as well as the [excellent guide on the Gentoo wiki]. I also think that the subsection on signing EFI binaries and kernels should be moved to it's own section, as this is relevant regardless of whether you are using your own keys, shim, or preloader.
- Soroshi (talk) 20:24, 24 December 2019 (UTC)
An alternative to signing the UEFI driver of the video card is enrolling its hash into db, as sbctl developer discusses on the github wiki: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom This can be done using the "at best experimental" -t option of sbctl. He also discusses how to check if there were any third party UEFI drivers signed with the Microsoft key using TPM. I checked ASUS UX325 laptop (Intel 11th Gen CPU with integrated graphics) using this method, and there were no third party drivers. I removed the Microsoft keys, and nothing is bricked.
Crankycrank (talk) 19:20, 22 January 2023 (UTC)
Booting Windows with custom bootloader signature
Windows 10 can boot with custom bootloader signature. I signed bootmgfw.efi and Windows still works normally.
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010 signature 2 image signature issuers: - /CN=[redacted] - Secure Boot DB image signature certificates: - subject: /CN=[redacted] - Secure Boot DB issuer: /CN=[redacted] - Secure Boot DB
I don't currently have any other keys enrolled, apart from mine.
$ efi-readvar
Variable PK, length 863
PK: List 0, type X509
Signature 0, size 835, owner [redacted-2]
Subject:
CN=[redacted] - Secure Boot PK
Issuer:
CN=[redacted] - Secure Boot PK
Variable KEK, length 865
KEK: List 0, type X509
Signature 0, size 837, owner [redacted-2]
Subject:
CN=[redacted] - Secure Boot KEK
Issuer:
CN=[redacted] - Secure Boot KEK
Variable db, length 863
db: List 0, type X509
Signature 0, size 835, owner [redacted-2]
Subject:
CN=[redacted] - Secure Boot DB
Issuer:
CN=[redacted] - Secure Boot DB
Variable dbx has no entries
Variable MokList has no entries
(fields replaced with [redacted] have the same value; same goes for [redacted-2])
I am not sure if it works for others. For reference, my machine is a ThinkPad E14, machine type 20RA. Maybe someone can confirm this on their machines and add something to the wiki?
P/s : maybe a method to automatically sign updates from Microsoft?
Cipher (talk) 04:59, 5 November 2020 (UTC)
Hi Cipher! I tried booting Windows via bootmgfw, signed with
- both Microsofts key
- and my personal key,
- in SecureBoot mode enabled,
- with my personal SecureBoot keys enrolled in NVRAM;
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows:
Selected boot image did not authenticate. Press ENTER to continue.
It seems like my BIOS can only read the first signature of binary EFI files, not multiple signatures of bootmgfw.efi . My signature on bootmgfw.efi was the second one; Microsofts signature was the first one:
If I delete the Microsoft signature from bootmgfw.efi and only add my own signature, I can get into Windows10 - but only in a Windows10 recovery/repair environment: Windows complains that my Windows10 installation is broken (because the Microsoft Windows signature on bootmgfw.efi is missing).
My BIOS firmware: UEFI 2.31 (INSYDE Corp. 4096.01)
My BIOS firmware in detail:
$ sudo dmidecode -t bios # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.7 present. Handle 0x000E, DMI type 0, 24 bytes BIOS Information Vendor: Insyde Version: F.70 Release Date: 07/18/2016 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 4 MB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported Japanese floppy for NEC 9800 1.2 MB is supported (int 13h) Japanese floppy for Toshiba 1.2 MB is supported (int 13h) 5.25"/360 kB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) 8042 keyboard services are supported (int 9h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 15.112 Firmware Revision: 29.66
So I suppose my UEFI/BIOS implementation is broken. My BIOS can probably only read the first signature of signed binary EFI files.
Here's my code:
$ cd /esp/EFI/Microsoft/Boot
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \
--output bootmgfw.efi.signed bootmgfw.efi
Image was already signed; adding additional signature
$ mv bootmgfw.efi bootmgfw.efi.backup $ mv bootmgfw.efi.signed bootmgfw.efi
$ sbverify --list bootmgfw.efi.backup signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010
$ sbverify --list bootmgfw.efi signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010 signature 2 image signature issuers: - /CN=<redacted> DB image signature certificates: - subject: /CN=<redacted> DB issuer: /CN=<redacted> DB
$ cd /esp/EFI/BOOT/
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \
--output bootx64.efi.signed bootx64.efi
$ mv bootx64.efi bootx64.efi.backup $ mv bootx64.efi.signed bootx64.efi
$ sbverify --list bootx64.efi.backup signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010
$ sbverify --list bootx64.efi signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010 signature 2 image signature issuers: - /CN=<redacted> DB image signature certificates: - subject: /CN=<redacted> DB issuer: /CN=<redacted> DB
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft:
$ efi-readvar
Variable PK, length 843
PK: List 0, type X509
Signature 0, size 815, owner <redacted>
Subject:
CN=<redacted> PK
Issuer:
CN=<redacted> PK
Variable KEK, length 845
KEK: List 0, type X509
Signature 0, size 817, owner <redacted>
Subject:
CN=<redacted> KEK
Issuer:
CN=<redacted> KEK
Variable db, length 843
db: List 0, type X509
Signature 0, size 815, owner <redacted>
Subject:
CN=<redacted> DB
Issuer:
CN=<redacted> DB
Variable dbx, length 76
dbx: List 0, type SHA256
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000
Hash:0000000000000000000000000000000000000000000000000000000000000000
I have booted into SecureBootMode:
$ bootctl status
System:
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)
Secure Boot: enabled
Setup Mode: user
TPM2 Support: no
Boot into FW: supported
DasMenschy (talk) 16:49, 21 September 2021 (UTC)
- Yeah, your firmware doesn't seem to recognize additional signatures from a binary. Did you try to append Microsoft's key to the signature database (the
dbvariable)? - (By the way, please indent your replies next time. It would be easier for people to separate out messages.)
- Cipher (talk) 15:39, 21 December 2021 (UTC)
- Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 (MicWinProPCA2011_2011-10-19.crt ) into the UEFI Secure Boot
dbvariable; I am able to boot Windows. But I wanted to achieve it without enrolling any Microsoft key into the db variable. I would like to avoid future security holes like BOOTHOLE, which AFAIK were introduced because Microsoft signs almost anything (probably including government surveillance tools). As far as I know, Microsoft doesn't really check the programs it signs for security vulnerabilities. - Currently, I am working around it by only enrolling the hashes of
bootmgfw.efiinto thedbvariable - then Windows can also be booted, but without the Microsoft UEFI keys. But of course, that's a lot of work: every time thebootmgfw.efichanges because of a Windows 10 update, I also have to update thedbvariable. And at some point in the future, the db variable stored on small NVRAM will be full - no more hashes can be added. So another solution would be nice. DasMenschy (talk) 21:32, 21 December 2021 (UTC)
- Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 (MicWinProPCA2011_2011-10-19.crt ) into the UEFI Secure Boot
- Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.
- Regarding the issue with automating hash enrollment, I have not found a solution either. So far, the Windows binary has to be signed/enrolled before booting, and I do not know whether that is possible inside Windows itself during updates. If that is not the case, you will have to reboot back to Linux to do it, be it automatic or manual (I semi-automated that with the pacman hook as described in the wiki page).
- About the
dbvariable, I believe you can wipe it and reinstall your own keys with fresh Windows hashes to deal with space issues (not sure if that could be done inside Linux though). Automate it (maybe a hook at kernel signing? After all, kernel updates are released more frequently than Windows updates, right?) and the issue should be resolved. - Also, I am not sure if Windows requires Microsoft signature to be the first - but if it doesn't, maybe we can do some shenanigans to switch your signature to the first entry, effectively satisyfing both Secure Boot and Windows?
- Cipher (talk) 02:17, 22 December 2021 (UTC)
Add a warning to warn users about dodgy firmware
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented in this issue. The summary of this is: Secure Boot means that all Option-ROMs must be signed and I used custom keys (with sbctl). The firmware decided it has to validate the Option-ROMs with my custom keys now, which fails. Since my setup did not have an integrated GPU/APU the GPU did not get initialized (since the Option-ROM could not be validated, for some reason an internal GPU/APU does not need one) and the motherboard failed to POST and got caught in a loop. I had to send my motherboard to MSI so they could "repair" the firmware.
I am not a firmware expert, but this might affect other motherboards too. Since some firmwares can behave strange, I am in favor of maybe adding a warning mentioning potential consequences, especially when not using the Microsoft keys.
A very similar issue is apparently present in some Dell motherboards.
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing /sys in a chroot for example, is vaguely related. I heard this is common in Lenovo devices, so not only my specific motherboard (vendor) has related firmware quirks and this is why this maybe warrants a Template:Warning.
-- NetSysFire (talk) 02:51, 1 April 2021 (UTC)
I've added a warning note at the beginning of the section about using your own custom keys. Some people have complained that their Thinkpad laptops were also bricked in this fashion, so it seems best to warn people to be cautious and do further research before proceeding. Tensa zangetsu (talk) 20:40, 15 May 2021 (UTC)
- The current warning isn't much help in finding out if one's device is going to be affected. Is this reliable enough to be added to the wiki as a possible check ? --Cvlc (talk) 21:44, 30 December 2021 (UTC)
Simplify the page by removing old instructions
There is a lot of text and alternative solutions to the same problems on this page. For instance, do we really need openssl, when sbkeys gets the job done just fine? Because there is no clear structure of alternative paths, the procedure is hard to follow even though I have done this many times before. I suggest either removing the older options, or moving them to separate pages, leaving only the most modern / automated workflow on the main article. A related concern is the manual creation of the /etc/secureboot/keys directory tree. Is there no tool that automatically puts the keys in the right folders, while also creating all the keys, optionally including the Microsoft ones? Foonoxous (talk) 15:16, 27 November 2021 (UTC)
about restoring OEM keys
This is a little off-topic, but: What about a mention that some firmware utility (BIOS) allow you to restore OEM keys, if cleared and deleted to enable back Secure Boot in User Mode, to quit Setup Mode
—This unsigned comment is by Solstice (talk) 14:12, 5 August 2022. Please sign your posts with ~~~~!
- Yes, that's a good point, it should be mentioned in this article that many UEFI implementations allow you to restore default / OEM keys! Where would you put that information?
- Option 1: At the end of section "3.1 Using your own keys", just after "3.1.7 Dual booting with other operating systems", a section: "3.1.8 Restoring the OEM Secure Boot variables"?
- Option 2: Or included in the section "3.1.2 Backing up current variables"?
- DasMenschy (talk) 21:27, 5 August 2022 (UTC)
Section "Shim with key and GRUB"
Concerning the section Unified Extensible Firmware Interface/Secure Boot#Shim with key and GRUB:
Do you think it is necessary to include an explanation what all the "basic" GRUB modules are doing, in the first code block? I couldn't find any good documentation about all these modules, I only found this thread on linux.org, which doesn't have all modules however and is already outdated. The official GNU GRUB manual has no documentation at all about the modules.
Do you think dividing the list of GRUB modules into these three parts, as done in the official Ubuntu build script, is meaningful, or is it arbitrarily / nonsensical?
Thank you in advance for help!
DasMenschy (talk) 12:42, 28 August 2022 (UTC)
- This section is definitely not up to the quality standards of the wiki. The linuxefi module referenced isn't even in upstream GRUB, it's a fedora-specific patch (also adopted by ubuntu). Also the GRUB_MODULES variable expansion should be between parentheses. Unless one requires the flexibility of GRUB, I suppose the best way to use Secure Boot with shim and machine owner key (on oem laptops with inflexible bios options for Secure Boot) is going the Unified Kernel Image way and using pacman hooks for that Blaatschaap (talk) 12:30, 11 October 2022 (UTC) EDIT: turns out this does not work either, with newer shim (from 15.3rc4+, pretty old by now) you need to build GRUB with fedora patches due to shim hardening Blaatschaap (talk) 12:55, 11 October 2022 (UTC)
- Hi User:Blaatschaap, the problem with the approach you mentioned is however that shim (with the Microsoft signature) can only launch a bootloader file called "grubx64.efi". So if you want to go the "shim + Unified kernel Image" way, you would have to call the Unified kernel image file "grubx64.efi". That's a quite dirty hack and quite irritating. You must trick shim into treating the Unified kernel image file as if it were the grub file.
- The file path / file name "grubx64.efi" is hard-coded (!) into the binary shim file. You could compile shim yourself, so that shim can also launch other binaries, that are not called "grubx64.efi", but these shim files then won't have any Microsoft signature; so they won't work on OEM laptops. Somehow Microsoft forced the shim developers to hardcode "grubx64.efi" into the binary shim file. I hate Microsoft because of that. Microsoft forces us to do dirty hacks.
- DasMenschy (talk) 13:06, 11 October 2022 (UTC)
- Hardcoding "grubx64.efi" into the shim binary does not offer any security benefit, but makes life harder for everyone. DasMenschy (talk) 13:13, 11 October 2022 (UTC)
- Nevertheless, if you call the Unified kernel image file "grubx64.efi" and if you include a sbat.csv file in it, I think you should be able to launch it with shim. That's the only thing necessary for the "shim hardening". This is not such a big problem. DasMenschy (talk) 13:13, 11 October 2022 (UTC)
- I do like what you did. I just made a bunch of style fixes; the most significant change was that I removed the direct excerpt of the Ubuntu build script because I don't want to paste a lot of code that we can just link to. Within the group of "basic" modules, an area of future expansion could be adding descriptions for (a subset of) them. -- CodingKoopa (talk) 18:15, 16 October 2022 (UTC)
I think the best way is to replace grub with
- refind or
- systemdboot
and then rename the
- "refindx64.efi" or
- "systemdbootx64.efi"
... file to "grubx64.efi", so that shim can launch them. The
- refind-install-script or
- systemdboot-install-script
... should then also drop a file in the grubx64.efi directory, explaining that the grubx64.efi file is not grub, like so:
- "grubx64-efi-is-not-grub-but-refind.txt" or
- "grubx64-efi-is-not-grub-but-systemdboot.txt"
- refind or
- systemdboot
... can then launch the Unified kernel image files. I think this approach is a bit more meaningful. But an explanation for this should not be put into the "grub" section, that's another topic.
DasMenschy (talk) 13:28, 11 October 2022 (UTC)