Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin]

Hi, Adrian.

 ---- On Sat, 14 Sep 2024 17:56:17 +0400  adrian15sgd  wrote --- 
 > Well, that needs more detailed explanation.

Debian has 4 signed GRUB images ( 
https://salsa.debian.org/grub-team/grub/-/blob/master/debian/build-efi-images?ref_type=heads
 ) (I will refer to this file as "build-efi-images"):

- gcdx64.efi
- grubx64.efi
- grubnetx64.efi
- grubnetx64-installer.efi

(Note that in this letter I will use the latest version of "build-efi-images", 
available at link above.)

(Again: versions of involved software matter. For example, as well as I 
understand, bookworm version of "build-efi-images" differs from the git 
version. So, when reading this letter use versions I use.)

So far when I wrote my previous letters I kept in mind grubx64.efi, not 
gcdx64.efi . And I wrote about boot process of debian installer, not debian 
live. Debian installer uses grubx64.efi and debian live uses gcdx64.efi . So, 
again: all I wrote in my previous letters applies to debian installer with 
grubx64.efi, not to debian live with gcdx64.efi .

Okay, now let me describe how boot process works. First I will talk about 
debian installer, and then about debian live. I got all this information from 
experiments.

Also: I suggest grubx64.efi as opposed to gcdx64.efi for super grub disk for 
reasons explained below.

Part 1. Debian installer.

I will use this image 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
 .

Note that this image (specially: iso fs) contains file /.disk/mkisofs, which 
contains the exact xorriso invocation, which created this image.

Iso fs contains file /boot/grub/efi.img , which is ESP partition (EFI System 
Partition). This partition (i. e. fat fs) contains these 3 files: 
/efi/boot/bootx64.efi , /efi/boot/grubx64.efi and /efi/debian/grub.cfg . (Yes, 
we see /efi here, not /EFI, but this is not important, because this is a FAT 
filesystem, and so it is case-insensitive.)

Main fs, i. e. iso fs, contains exactly the same files (but with EFI, not efi).

Part 1.1. UEFI CD boot

Firmware executes /efi/boot/bootx64.efi from ESP (which is shim). The shim 
executes /efi/boot/grubx64.efi from ESP (which is grubx64.efi , not 
gcdx64.efi). grubx64.efi loads /EFI/debian/grub.cfg from iso fs (not from ESP). 
grubx64.efi does this, because this path is hardcoded in the binary. It is 
hardcoded, because "build-efi-images" builds grubx64.efi using 'grub-mkimage -p 
"/EFI/$efi_vendor" ...', and $efi_vendor is "debian". grubx64.efi has no "early 
config". Also grubx64.efi has memdisk, but the memdisk doesn't have any 
configuration, so memdisk doesn't affect boot logic.

Okay, so /EFI/debian/grub.cfg from iso fs is loaded. This is a short file, 
which finds iso fs root using "search --file --set=root 
/.disk/id/dae2967f-d173-4909-90fd-7cb26e6945dc". In this particular case this 
is not needed, because $root is already set to iso fs. So this "search" is 
no-op. Then /EFI/debian/grub.cfg sets $prefix and loads 
/boot/grub/x86_64-efi/grub.cfg from iso fs, which is "real" grub config.

Part 1.2. UEFI USB boot

Exactly the same thing happens as we know from UEFI CD boot. With the following 
changes. grubx64.efi loads /EFI/debian/grub.cfg from ESP, not from iso fs. (But 
these two files are same anyway.) Then this /EFI/debian/grub.cfg performs 
"search --file --set=root /.disk/id/dae2967f-d173-4909-90fd-7cb26e6945dc", and 
this time this "search" is not no-op. It actually matters. Because it changes 
$root from ESP to iso fs. Then /EFI/debian/grub.cfg sets $prefix and loads 
/boot/grub/x86_64-efi/grub.cfg from iso fs, which is "real" grub config.

Part 2. Debian live

I will use 
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-standard.iso

This image also contains /.disk/mkisofs , which contains xorriso invocation.

This image (i. e. iso fs) contains /boot/grub/efi.img , which is ESP partition.

ESP contains 3 files: /EFI/boot/bootx64.efi (shim), /EFI/boot/grubx64.efi (this 
is actually gcdx64.efi , as opposed to debian installer) and 
/boot/grub/grub.cfg .

These 3 files are NOT identical to corresponding files on iso fs (as opposed to 
debian installer). I. e. bootx64.efi and grubx64.efi seem to be identical. But 
/boot/grub/grub.cfg is not.

Part 2.1. UEFI CD boot

Firmware executes /EFI/boot/bootx64.efi from ESP. bootx64.efi executes 
/EFI/boot/grubx64.efi from ESP.

grubx64.efi (which is actually gcdx64.efi), as opposed to real grubx64.efi , 
contains so-called early config. I know this, because in "build-efi-images" I 
see that gcdx64.efi is generated using "grub-mkimage -c ... ...". Option "-c" 
means early config. That early config loads grub.cfg from memdisk. Memdisk's 
grub.cfg is a complicated "if"-based script. You can see it in 
"build-efi-images". I will not explain in detail how this "grub.cfg" works. 
(But if you want, I can explain it.) Anyway, this "grub.cfg" loads 
/boot/grub/x86_64-efi/grub.cfg from iso fs (we booted using UEFI CD, so $root 
is already set to iso fs).

/boot/grub/x86_64-efi/grub.cfg from iso fs loads /boot/grub/grub.cfg from iso 
fs, which is the main config.

Part 2.2. UEFI USB boot

Everything is the same as part 2.1 with the following changes. When grub.cfg 
from memdisk is executed, $root is set to ESP, not to iso fs. So grub.cfg from 
memdisk executes differently. (Again, I will not get into details about how it 
is executed, but you can ask me.) This time grub.cfg from memdisk loads 
/boot/grub/grub.cfg from ESP. This /boot/grub/grub.cfg executes "search 
--set=root --file /.disk/info". This command finds the real root, i. e. iso fs. 
I. e. this command changes $root from ESP to iso fs. Of course, this is very 
fragile, because we simply switch to whatever disk, which contains /.disk/info 
. This will not work if our system has multiple live debian disks inserted. I 
think this is a bug, so I reported it to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081041 . So I suggest using 
grubx64.efi as opposed to gcdx64.efi for super grub disk.

Okay, so /boot/grub/grub.cfg from ESP executed "search" and set $root. Then 
this /boot/grub/grub.cfg sets $prefix and loads /boot/grub/grub.cfg from iso 
fs, which is the main config.

Small note: I'm 100% sure about how debian installer boot process works. 
Because I did a lot of experiments. And I'm 90% sure about how debian live boot 
process works. Because I didn't perform any experiments with debian live. I 
simply applied my knowledge, gained from debian installer experiments, to 
debian live boot process. So, we get 90% only, not 100%. My main doubt about 
debian live boot process is how grub.cfg from memdisk is executed. I didn't do 
any experiments with this grub.cfg, I simply have read it and executed in my 
head. printf-debugging would be certainly better. I. e. what I really should do 
is to insert "echo" commands to this grub.cfg, then regenerate gcdx64.efi 
(using code from "build-efi-images") (unsigned, of course), then regenerate 
debian live image (for example, by reexecuting command from /.disk/mkisofs ) 
and then run it in qemu. I did not do this, you can do this if you want. I can 
explain in more detail how to do this, this is easy.

But again: I'm 90% sure about how debian live boot process works. 90% is a high 
probability.

Okay, so hopefully I explained everything.

If you have any questions, ask me.

Also: when I said "GRUB searches for files in ISO fs when booted from CD (in 
UEFI mode)", I meant that GRUB itself (not any kind of configs) sets $root to 
iso fs, when booted as UEFI-CD. This is how GRUB itself works, this is not 
related to Debian GRUB images or any particular configs. It is even possible 
that reasons are even deeper, i. e. reason is not GRUB, but UEFI itself or 
something.

Anyway, when we boot using UEFI-CD, $root is set to iso fs, and when we boot 
using UEFI-USB, $root is set to ESP. This applies to all GRUB images, not 
necessary to Debian GRUB images. And we should keep this in mind when we 
execute any kind of GRUB configs in our heads.

But there is a note here: this applies in these two situations:
1. GRUB image was generated without memdisk
2. GRUB image was generated with memdisk, but when generating -p option (to 
grub-mkimage) was set after -m option

In these two situations $root will be set as I described above (I know this 
from experiments). There is also 3rd situation:
3. GRUB image was generated with memdisk, and there was no -p option after -m

Well, I don't know what will happen in this case, I didn't do experiments on 
this.

Also, my algorithm on determining $root applies if prefix set using -p option 
to grub-mkimage starts with "/", for example, /boot/grub. I don't know what 
will happen if it starts from "(" or anything else.

 > A Debian live cd as you have pointed out reuses a gcdx64.efi file.

Yes.

 > That gcdx64.efi file has an embedded memdisk with a special grub.cfg. 

Yes. As I explained above, first early config is executed, then it executes 
grub.cfg from memdisk.

 > Then that special grub.cfg finds those CD files and configfiles to there.

Yes. I explained above how this happens. Also, it "sources", not "configfiles", 
according to "build-efi-images" from current git.

 > As I want to be able to read the ElTorito image contents somehow

I don't know terminology here well. What do you mean by ElTorito image? You 
mean ESP partition? And you want to extract ESP partition from official debian 
live image? This is easy. Mount iso image. You will see xorriso command in 
/.disk/mkisofs . That command mentions /boot/grub/efi.img . So this is ESP. 
Just mount it.

 > I am 
 > actually trying to build a barebones Grub ElTorito image for UEFI CD 
 > boot in my Rescatux development streams.

I can help. Just tell exactly what you are trying to build. GRUB image? I. e. 
what is generated by grub-mkimage? Or .iso? Or both? Or ESP?! Tell in detail 
what you want to build and I will give you commands to do this.

 > I want to check what actually happens in that scenario without an 
 > embedded memdisk.

Again: tell in details what you want to check. I will try to give you commands.

--
Askar Safin
https://types.pl/@safinaskar