Jump to content











Photo
- - - - -

Running an unsigned boot loader with Secure Boot enabled


  • Please log in to reply
No replies to this topic

#1 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 18 March 2023 - 05:01 PM

A more detailed guide including screenshots is available - refer to http://mistyprojects.../secureboot.htm


The methods and tools used in this post are the work of ValdikSS, based on their Super UEFIinSecureBoot Disk


This guide uses files from the Super UEFIinSecureBoot Disk - required files can be extracted from Super-UEFIinSecureBoot-Disk_minimal_v3-4.zip (7-zip can be used to extract the files - alternatively the core files have been extracted here for convenience).


The Super UEFIinSecureBoot Disk is a three stage boot loader. The following files are loaded on 64-bit systems -
\EFI\BOOT\bootx64.efi > \EFI\BOOT\grubx64.efi > \EFI\BOOT\grubx64_real.efi


List of files to be extracted from Super-UEFIinSecureBoot-Disk_minimal_v3-4.zip -
  • \EFI\BOOT\BOOTX64.EFI - stage one 64-bit boot loader. Currently based on Red Hat shim (v15-8) from Fedora. This file is signed with a Microsoft key and is used for the initial boot stage 1
  • \EFI\BOOT\grubx64.efi - stage 2 64-bit loader. Modified Linux Foundation PreLoader. This is used to circumvent UEFI Security Policy to chainload unsigned .efi files. This stage 2 loader (chainloaded by \EFI\BOOT\bootx64.efi) will chainload the stage 3 loader \EFI\BOOT\grubx64_real.efi
  • \EFI\BOOT\mmx64.efi - 64-bit MOK (Machine Owner Key) manager. This program will automatically be loaded by the stage 1 loader if the firmware does not have an entry for the stage 2 loader enrolled in the UEFI Secure Boot key database. This process is only required once. If the key is enrolled successfully then the stage 2 loader will automatically load.
  • \EFI\BOOT\bootia32.efi - Stage 1 32-bit boot loader. Refer to more detailed information in the \EFI\BOOT\bootx64.efi section above.
  • \EFI\BOOT\grubia32.efi - Stage 2 32-bit boot loader. Refer to more detailed information in the \EFI\BOOT\grubx64.efi section above.
  • \EFI\BOOT\mmia32.efi - 32-bit MOK (Machine Owner Key) manager. Refer to more detailed information in the \EFI\BOOT\mmx64.efi section above.
  • \ENROLL_THIS_KEY_IN_MOKMANAGER.cer - Digital certificate for \EFI\BOOT\grubx64.efi\\EFI\BOOT\grubia32.efi. As these files do not contain an embedded Fedora certificate (required for the stage 1 loader to automatically load stage 2) MOK manager will be loaded and can be used to install this digital certificate, allowing the stage 2 loader to load successfully on subsequent boots.
The stage 1 and stage 2 files are extracted from the Super UEFIinSecureBoot Disk. As the stage 2 loader can be used to chainload unsigned files, any 64-bit boot loader can be saved as \EFI\BOOT\grubx64_real.efi or 32-bit boot loader saved as \EFI\BOOT\grubis32_real.efi. I have a preference for GRUB4EFI. Download the Grub4dos_for_UEFI -
  • 64-bit - Extract bootx64.efi and rename as grubx64_real.efi (path \EFI\BOOT\grubx64_real.efi)
  • 32-bit - Extract bootia32.efi and rename as grubx64_real.efi (path \EFI\BOOT\grubia32_real.efi)
One of the advantages of UEFI over BIOS is the built in support for file systems. This makes it relatively easy to create a bootable USB drive to launch a third party UEFI boot manager. The UEFI specification "...mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.9, section 13.3. 1.1), but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system..." To ensure compatabiliy on as wide a range of systems as possible, FAT32 is recommended. Due to the filesystem support, file based copying can be used to create a bootable drive - boot code does not need to be edited and active flags do not need to be set. To create a basic UEFI bootable drive, format as FAT32 and create the following directory structure (with paths relative to the volume root) -

\EFI\
\EFI\boot\
\EFI\boot\bootia32.efi
\EFI\boot\bootx64.efi
\EFI\boot\grubia32.efi
\EFI\boot\grubia32_real.efi
\EFI\boot\grubx64.efi
\EFI\boot\grubx64_real.efi
\EFI\boot\mmia32.efi
\EFI\boot\mmx64.efi
\ENROLL_THIS_KEY_IN_MOKMANAGER.cer


As the system is unlikely to have a digital key for the stage 2 boot loader (grubia32.efi\grubx64.efi) enroled in the firmware on first boot, the MOK manager will be launched automatically. The following steps show the process for installing the digital certificate (\ENROLL_THIS_KEY_IN_MOKMANAGER.cer) for the stage 2 loader (\EFI\BOOT\grubx64.efi)
  • ERROR > the Verification Failed message is displayed when the stage 2 loader does not have a digital certificate enrolled in the UEFI Secure Boot key database. Seleck OK > Enter
  • Shim UEFI key management > Press any key within the 10 second time limit to progress with MOK management and enrolling the digital certificate
  • Perform MOK management > Select the option Enroll key from disk > Enter
  • Select Key > Select the disk/volume containing your digital certificate/key file. On the test system only one volume was available - this was the EFI system partition with volume label NVME1
  • Select Key > Browse to ENROLL_THIS_KEY_IN_MOKMANAGER.cer > ENTER
  • Enroll MOK > Select Continue
  • Enroll the key(s)? > Select Yes
  • Perform MOK management > Select Reboot
cheers.gif

Misty

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 March 2023 - 06:25 PM

Doesn't the partition need to be an ESP one, i.e. with ID  0xEF (MBR) or C12A7328-F81F-11D2-BA4B-00A0C93EC93B (GPT)? :dubbio:

 

https://en.wikipedia...ystem_partition

 

:duff:

Wonko

 



#3 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 18 March 2023 - 07:33 PM

Doesn't the partition need to be an ESP one, i.e. with ID  0xEF (MBR) or C12A7328-F81F-11D2-BA4B-00A0C93EC93B (GPT)? dubbio.gif
 
https://en.wikipedia...ystem_partition
 
duff.gif
Wonko

@Wonko
The partition may need to be an ESP on an internal drive, however it's booting fine on my MBR type external HDD.

A lot will depend on the system firmware implementation. UEFI reminds me of the inconsistencies in USB boot support when I first discovered BartPE nearly 20 years ago.

Misty



#4 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 19 March 2023 - 07:53 AM

@Wonko
I had no idea that ESP was supported on MBR type disks, so thanks for your link. I have investigated further on my test system.

The DiskPart create partition EFI (usually used to create EFI system partition) cannot be used to create EFI type partitions (ESP) on MBR type disks. Attempting to do so resulted in the following error -
DISKPART> create partitition efi

MSR and EFI partitions are only supported on GPT disks.
Convert the selected disk to GPT and try again.
The set id= command can be used - more in my next post.

Used DiskPart to create a primary partition and formatted it as FAT32 with volume label BOOT

Edited MBR sector 0x1C2 and changed partition type to 0xEF (using a hex editor).

Removed the USB drive from the system and reinserted it to ensure that the manual edits were detected properly by Windows disk management.

DiskPart output -
DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *
  Disk 1    Online         1905 MB      0 B

DISKPART> sel disk 1

Disk 1 is now the selected disk.

DISKPART> detail disk

Kingston DataTraveler2.0 USB Device
Disk ID: F501346B
Type   : USB
Status : Online
Path   : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : No
Read-only  : No
Boot Disk  : No
Pagefile Disk  : No
Hibernation File Disk  : No
Crashdump Disk  : No
Clustered Disk  : No

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 4     E                       Removable   1905 MB  Unusable

Note that based on the output of the detail volume command, the status is listed as Unusable! It is however still accessible in Explorer and is writable.

GRUB4EFI (booted via bootx64.efi > grubx64.efi > grub_real.efi) booted ok on my Thinkpad T470s test system - with partition type set as EF and when retested with partition type 0C.

DiskPart does not accurately report information on this disk with partition type set as 0xEF. Lets look at the output from running the detail partition command, with volume information missing -
DISKPART> sel part 1

Partition 1 is now the selected partition.

DISKPART> detail part

Partition 1
Type  : EF
Hidden: No
Active: Yes
Offset in Bytes: 65536

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------

DISKPART>

Compare this to output from ESP on an internal disk (GPT disk) -
DISKPART> sel part 1

Partition 1 is now the selected partition.

DISKPART> detail part

Partition 1
Type    : c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Hidden  : Yes
Required: No
Attrib  : 0X8000000000000000
Offset in Bytes: 1048576

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 3         BOOT         FAT32  Partition   2048 MB  Healthy    System

DISKPART>

Based on information in the link you sent me, on removable media "...UEFI firmware supports booting from removable storage devices such as USB flash drives. For that purpose, a removable device is formatted with a FAT12, FAT16 or FAT32 file system, while a boot loader needs to be stored according to the standard ESP file hierarchy.....On the other hand, FAT32 is always expected on fixed drives...."

I am fairly sure that on an old system of mine (ThinkPad w530) I was able to boot in UEFI mode from an internal MBR type disk with a standard (none ESP - partition type 0x0C) 2GB FAT32 partition containing the UEFI boot files. Unfortunately I am not in a position to retest. I recall that a similar test/setup failed on a newer generation of ThinkPad. Again, I am going on memory here and I'm getting old.

cheers.gif

Misty

#5 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 19 March 2023 - 11:14 AM

Wonko mentioned in his post (#2) that the UEFI standard includes support for EFI System Partition (ESP) on MBR type disks - partition type is hex 0xEF.

As I mentioned in my previous post, the DiskPart set command is required as the create partition efi command fails on MBR disks -
DISKPART> clean

DiskPart succeeded in cleaning the disk.

DISKPART> create part efi

MSR and EFI partitions are only supported on GPT disks.
Convert the selected disk to GPT and try again.
Information about the DskPart set command

DISKPART> help set

    Changes the partition type field for the partition with focus.

Syntax:  SET ID={<BYTE> | <GUID>} [OVERRIDE] [NOERR]

    ID={<BYTE> | <GUID>}

                Specifies the new partition type.

                For master boot record (MBR) disks, you can specify a partition
                type byte, in hexadecimal form, for the partition. Any
                partition type byte can be specified with this parameter except
                for type 0x42 (LDM partition). Note that the leading '0x' is
                omitted when specifying the hexadecimal partition type.

                For GUID partition table (GPT) disks you can specify a
                partition type GUID for the partition. Recognized GUIDs
                include:

                    EFI System partition:
                        c12a7328-f81f-11d2-ba4b-00a0c93ec93b

                    Basic data partition:
                        ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

                Any partition type GUID can be specified with this parameter
                except for the following:

                    Microsoft Reserved partition:
                        e3c9e316-0b5c-4db8-817d-f92df00215ae

                    LDM Metadata partition on a dynamic disk:
                        5808c8aa-7e8f-42e0-85d2-e1e90434cfb3

                    LDM Data partition on a dynamic disk:
                        af9b60a0-1431-4f62-bc68-3311714a69ad

                    Cluster Metadata partition:
                        db97dba9-0840-4bae-97f0-ffb9a327c7e1


                Other than the limitations mentioned, DiskPart otherwise does
                not check the partition type for validity except to ensure that
                it is a byte in hexadecimal form or a GUID.

    OVERRIDE    Enables DiskPart to force the file system on the volume to
                dismount before changing the partition type. When changing
                the partition type, DiskPart will attempt to lock and dismount
                the file system on the volume. If this parameter is not specified,
                and the call to lock the file system fails, (because some other
                application has an open handle to the volume), the entire
                operation will fail. When this parameter is specified, the
                dismount is forced even if the call to lock the file system
                fails. When a file system is dismounted, all opened handles to
                the volume will become invalid.

    NOERR       For scripting only. When an error is encountered, DiskPart
                continues to process commands as if the error did not occur.
                Without the NOERR parameter, an error causes DiskPart to exit
                with an error code.

    Intended for Original Equipment Manufacturer (OEM) use only.

    A partition must be selected for this operation to succeed.

    Caution:

        Changing partition type fields with this parameter might cause your
        computer to fail or be unable to start up. Unless you are an OEM or an
        IT professional experienced with GPT disks, do not change partition
        type fields on GPT disks using this parameter. Instead, always use the
        CREATE PARTITION EFI command to create EFI System partitions, the
        CREATE PARTITION MSR command to create Microsoft Reserved partitions,
        and the CREATE PARTITION PRIMARY command without the ID parameter to
        create primary partitions on GPT disks.

    This command does not work on dynamic disks nor on Microsoft Reserved
    partitions.

    Example:

    SET ID=07 OVERRIDE
    SET ID=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

DISKPART>
I was able to use the following to create an 0xEF partition on my drive -

DISKPART> create partition primary

DiskPart succeeded in creating the specified partition.

DISKPART> format fs=fat32 label=USB quick

  100 percent completed

DiskPart successfully formatted the volume.

DISKPART> set id=EF

DiskPart successfully set the partition ID.

DISKPART>


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 March 2023 - 02:42 PM

Yep.

 

Now that you have touched it with your hands, you have evidence how the 0xEF partition type does not really exist outside the (wild) dreams of the UEFI specs and of its promoters.

 

In practice, on MBR any partition ID will do (i.e. boot), as long as the partition is active in the MBR partition table normal 0x0B or 0x0C will do fine, Windows uses (when installed/setup by the MS tools) partition type 0x27.

 

None of the good MS guys (AFAIK) ever used 0xEF in Windows (and there are only few people, including our friend Akeo/p.batard) that notice this kind of things on other platforms/OSes, and - only as an example - on raspberrypi support for it had to be added:

 

https://github.com/r...prom/issues/126

 

(I think it is now on the RPi4 but not on the RPi3)

 

 

What makes the volume boot (in BIOS) is the active flag and the code in the MBR and PBR.

 

On UEFI/GPT, instead, in theory you actually need the c12a7328-f81f-11d2-ba4b-00a0c93ec93b as it tells to the UEFI firmware (still in theory) to look there for the .efi bootloader.

 

I suspect that when UEFI booting from a MBR disk, it is as well the active flag that tells the UEFI firmware to look for the .efi bootloader on that partition, BUT it is also possible that the firmware attempts to scan all primary partitions. :unsure:

 

 

:duff:

Wonko



#7 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 19 March 2023 - 05:16 PM

....I suspect that when UEFI booting from a MBR disk, it is as well the active flag that tells the UEFI firmware to look for the .efi bootloader on that partition, BUT it is also possible that the firmware attempts to scan all primary partitions. unsure.png...


I was curious, so I've just tested using an old 2GB USB 2 MBR type disk with the following partition structure -

  • (hd#,0) - type 0xEF (FAT32)- active
  • (hd#,1) - type 0x07 (NTFS)
  • (hd#,2) - type 0x0C (FAT32)

First test - UEFI boot files only on (hd#,2) - booted to GRUB4EFI

Second test - UEFI boot files only on (hd#,1) - failed to boot

Third test - UEFI boot files only on (hd#,0) - booted to GRUB4EFI

On my system (ThinkPad T470s), active partition appears to be ignored and all supported primary partitions are scanned for UEFI boot files.

Misty



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 March 2023 - 09:36 AM

Yep.

 

I don't know if it is "general" or it is peculiar to some UEFI implementations, in the case that all primaries are scanned (provided that logical volumes are not scanned as well[1]) it has to be seen if the scanning stops when the first UEFI boot files are found or if all partitions are scanned anyway (and you are given an option to choose among the found boot files).

 

Just for the record/FYI, we also have the GPT partition type that was implemented in the specs but noone ever used in "normal" OS (still AFAIK) which is the "legacy MBR" type 024DEE41-33E7-11D3-9D69-0008C781F39F (that however allows for some tricks):

 

 

http://reboot.pro/in...showtopic=20002

 

 

:duff:

Wonko

 

[1] for what we (i) know UEFI might go beyond the concept of primary partitions/logical volumes and consider all volumes it can find as possible locations for boot files.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users