[PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot
Hi. I propose changing "efi" to "EFI" in grub-mkrescue, because this is needed
for secure boot. Please, apply patch below. Here is why.
First of all, iso9660 file system is case sensitive from GRUB point of view. I.
e. if you have directory named "efi" in iso9660, then GRUB command "ls /EFI"
will not work.
Second, it seems that "EFI", as opposed to "efi", is standard among Linux CDs.
I examined the following .iso files:
- Debian installer
- Debian live image
- Ubuntu live image
- Fedora network install
All they have "EFI", as opposed to "efi".
And main argument: I'm aware of one example when "EFI" is hard-coded in signed
secure boot GRUB binary. Debian has 4 signed GRUB binaries. All they are
generated here:
https://sources.debian.org/src/grub2/2.12-5/debian/build-efi-images/ . One of
them, grubx64.efi is created using "grub-mkimage ... -p /EFI/debian". The
binary is signed, so I cannot change it if I want secure boot support. So if I
want to use this binary, I should have directory named exactly "EFI".
You may say: "But grub-mkrescue doesn't support secure boot". Yes, it doesn't
support it. But I think this patch will simplify adding secure boot support by
distributions.
Now let me describe in detail why I need all this. Also I will show you results
of additional experiments.
I attempted to create bootable GRUB disk using grub-mkrescue. I wanted the disk
to support secure boot. I failed. I don't remember why. It is possible that
this EFI vs efi issue was one of the problems. So I resorted to writing script,
which replaces grub-mkrescue. This is simplified version of that script. Note:
this is simplification written specially for presenting here. So I
intentionally dropped things I would not drop in real code.
#!/bin/bash
# This script is merely demonstration created specially to present on GRUB
mailing list. So it intentionally drops some important things
# This script can be run on any Linux distro
# This script creates isohybrid disk, which supports UEFI booting
# The disk can be used both as CD image and as USB disk image
# So, in total 2 boot modes are supported: UEFI-CD and UEFI-USB
# Secure boot is supported
# This script can be run on any Linux distro (but was tested on Debian only).
# The script doesn't rely on specific files present in specific places, it
downloads all its dependencies
# This script doesn't support "EFI file system transposition" (
https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00024.html ). This is
intentional, because this is just a demo
# The script was tested in Qemu only. Also secure boot was not tested
{
# This is just boilerplate I insert to all my bash scripts
set -e
set -u
set -o pipefail
shopt -s inherit_errexit
shopt -s nullglob
export LC_ALL=C.UTF-8
if [ $# != 1 ]; then
echo "Usage: ${0##*/} OUT" >&2
exit 1
fi
OUT="$1"
DIR="$(mktemp -d /tmp/grub-XX)"
mkdir -p "$DIR/esp/EFI/boot" "$DIR/esp/EFI/debian"
"$DIR/main-root/EFI/debian" "$DIR/main-root/boot/grub"
wget -O "$DIR/esp/EFI/boot/bootx64.efi"
'https://sources.debian.org/src/shim-signed/latest/shimx64.efi.signed/'
wget -O "$DIR/grub-efi-amd64-signed.deb"
'https://deb.debian.org/debian/pool/main/g/grub-efi-amd64-signed/grub-efi-amd64-signed_1+2.12+5_amd64.deb'
ar p "$DIR/grub-efi-amd64-signed.deb" data.tar.xz > "$DIR/data.tar.xz"
tar -xf "$DIR/data.tar.xz" --to-stdout
./usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed >
"$DIR/esp/EFI/boot/grubx64.efi"
cat << "EOF" > "$DIR/esp/EFI/debian/grub.cfg"
echo "This is /EFI/debian/grub.cfg from ESP"
echo "Testing shows that this file is loaded during UEFI-USB"
sleep 10
EOF
mkfs.vfat -C "$DIR/main-root/boot/grub/efi.img" 1
mcopy -s -i "$DIR/main-root/boot/grub/efi.img" "$DIR/esp/EFI" ::/
cat << "EOF" > "$DIR/main-root/EFI/debian/grub.cfg"
echo "This is /EFI/debian/grub.cfg from main file system (iso9660)"
echo "Testing shows that this file is loaded during UEFI-CD"
sleep 10
EOF
# I don't know why this "$DIR/main-root/zero" is needed. Anyway this is just
a demo
dd if=/dev/zero of="$DIR/main-root/zero" bs=1M count=1
xorriso -as mkisofs -b /zero -no-emul-boot --efi-boot /boot/grub/efi.img
-efi-boot-part --efi-boot-image -o "$OUT" -r "$DIR/main-root"
rm -r "$DIR"
exit 0
}
While testing this script I noticed this: if I boot from disk (i. e. using
"-drive" Qemu option), then "grub.cfg" is read from ESP, i. e. FAT. But if I
boot from CD (i. e. using "-cdrom" Qemu option), then "grub.cfg" is read from
main .iso partition, i. e. iso9660. I don't know whether this is expected
behavior or just a bug.
FAT is case insensitive from GRUB point of view. But iso9660 is case sensitive.
So, the file (in case of CD boot) must be named exactly /EFI/debian/grub.cfg.
Name /efi/debian/grub.cfg will not work, I tested this. I. e. I replaced "EFI"
with "efi" everywhere in the script above and I saw that in case of UEFI-CD
file /efi/debian/grub.cfg is not read anymore.
Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot
On Sat, 07 Sep 2024 11:53:15 +0400 Vladimir 'phcoder' Serbinenko wrote --- > > And main argument: I'm aware of one example when "EFI" is hard-coded in > > signed secure boot GRUB binary. Debian has 4 signed GRUB binaries. All > > they are generated > > here:https://sources.debian.org/src/grub2/2.12-5/debian/build-efi-images/ > > . One of them, grubx64.efi is created using "grub-mkimage ... -p > > /EFI/debian". > Why do they use /EFI if it doesn't even work? I will repeat: I tried to create GRUB .iso for my own uses. And I noticed that grub-mkrescue is incompatible with GRUB EFI binaries signed by Debian for reasons explained in my previous letter. But official Debian .iso images seem to be created without grub-mkrescue, and for this reason creators of official images didn't get these problems. So, /EFI *does* work for people who create official ISOs, they just don't use grub-mkrescue. > The question is who needs to change this You mean should Debian change "EFI" to "efi" or GRUB change "efi" to "EFI"? Of course, I want whole Linux ecosystem to converge to some single name, "efi" or "EFI". What should we choose? As I said in first letter, major distros (Debian, Ubuntu and Fedora) already use "EFI" in their ISOs. And at least one of them (Debian) hardcode "EFI" to signed binary. So, of course, GRUB should be changed, not distros. Because it is easier. -- Askar Safin https://types.pl/@safinaskar ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot
On Wed, 11 Sep 2024 14:23:05 +0400 adrian15sgd wrote --- > No, I did not disable the SecureBoot support in Super Grub2 Disk because > of this "efi" to "EFI" supposed problem that you describe. I'm not talking about secure boot support in super grub disk. I'm talking about secure boot support on CD (as opposed to USB stick) in super grub disk. Currently it seems from release page ( https://www.supergrubdisk.org/2024/07/30/super-grub2-disk-2-06s4-released/ ), that secure boot downloads come as USB stick images only, not as CD. Note: I don't ASK for adding support for CDs, I'm not super grub disk user, i. e. this is not feature request. I'm just pointing that CDs are not supported, and I still suspect that that "EFI vs efi" problem is the reason. Anyway, I know how to create bootable GRUB CDs with secure boot support, so ask me if you have any questions. You can use script in my first letter ( https://lore.kernel.org/grub-devel/20240906132914.27842-1-safinas...@zohomail.com/ ) as starting point. -- Askar Safin https://types.pl/@safinaskar ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot
On Wed, 11 Sep 2024 14:38:31 +0400 Tobias Powalowski via Grub-devel wrote --- > I was not able to use virtualbox on my project until I put the kernel > also to the ISO fs I think, I suspect this is exactly same behaviour I'm talking about in my first letter. It is behaviour called "GRUB searches for files in ISO fs when booted from CD (in UEFI mode) and in ESP when booted from USB stick (in UEFI mode)". You seem to connect .iso to virtualbox as virtual CD as opposed to virtual USB stick. This is simply how GRUB works. This is exactly behaviour discussed in these letters in this thread: - https://lore.kernel.org/grub-devel/20240906132914.27842-1-safinas...@zohomail.com/ - https://lore.kernel.org/grub-devel/85fba0d5-de51-4736-9252-13576664c...@plouf.fr.eu.org/ - https://lore.kernel.org/grub-devel/29963309928969934...@scdbackup.webframe.org/ - https://lore.kernel.org/grub-devel/bcd9e556-9fe7-46ac-bc6f-68225b0fe...@plouf.fr.eu.org/ And this behaviour was surprise to author of xorriso. Anyway I would not call it a bug. -- Askar Safin https://types.pl/@safinaskar ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot
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
Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot
Oops, I meant grub-mkrescue, not grub-mkimage, in this mail. On Fri, 27 Sep 2024 20:10:30 +0400 Askar Safin wrote --- > So, what about my patch? I will repeat: my patch doesn't remove any existing > use cases and adds new use cases. It enables distros to implement secure > boot in grub-mkimage. As I already told with examples in my first letter, > Linux distros already converged to "EFI", not "efi". Current solution by > Debian is not to use grub-mkimage. My patch will allow Debian to use > grub-mkimage > > -- > Askar Safin > https://types.pl/@safinaskar > > > -- Askar Safin https://types.pl/@safinaskar ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot
So, what about my patch? I will repeat: my patch doesn't remove any existing use cases and adds new use cases. It enables distros to implement secure boot in grub-mkimage. As I already told with examples in my first letter, Linux distros already converged to "EFI", not "efi". Current solution by Debian is not to use grub-mkimage. My patch will allow Debian to use grub-mkimage -- Askar Safin https://types.pl/@safinaskar ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix screen coud be filled with leftover artifacts
On Thu, 03 Oct 2024 11:23:08 +0400 Michael Chang via Grub-devel wrote
---
> A regression in grub 2.12 causes the grub screen to become cluttered
I just tested. Your patch doesn't fix anything for me!
(Note: I'm not GRUB developer, I'm just a user.)
Hi. I'm annoyed by screen cluttering, too. So I applied this patch to see
whether this will help.
Unfortunately, it did not.
Here is my test setup: I boot GRUB x86_64-efi in Qemu. My grub.cfg is so:
echo "This is /EFI/debian/grub.cfg from main file system (iso9660)"
echo "Testing shows that this file is loaded during UEFI-CD"
sleep 10
As you can see, my grub.cfg does "sleep 10" before GRUB command line. Also,
note that there is no any "menuentry". So, menu is not shown.
Okay, so what happens?
Both with your patch and without your patch the following happens: I see
message "This is /EFI/debian/grub.cfg from..." on screen with artifacts, then,
after 10 seconds I switch to GRUB command line without artifacts.
So, yes, artifacts are not present at GRUB command line screen, but they ARE
present (both with and without your patch) before we switch to GRUB command
line.
Now let me describe my exact setup for testing this.
I checked out GRUB's master branch. Then I compiled it so (both with and
without your branch) (in debian sid x86_64 docker):
***
./bootstrap
./configure --prefix=/opt/grub --with-platform=efi
make
make install
***
Note that freshly built GRUB got to /opt/grub.
Then I built ".efi" file so (inside debian sid x86_64 docker):
***
/opt/grub/bin/grub-mkimage -O x86_64-efi -o /tmp/grub.efi -d
/opt/grub/lib/grub/x86_64-efi -p /EFI/debian all_video boot cat configfile
echo fat font gfxmenu gfxterm gfxterm_background help iso9660 loadenv ls
memdisk minicmd normal part_msdos part_gpt regexp search sleep test true video
***
Then I built ".iso" file by this script (inside debian sid x86_64 docker):
***
#!/bin/bash
# This script creates isohybrid disk, which supports UEFI booting
# The disk can be used both as CD image and as USB disk image
# So, in total 2 boot modes are supported: UEFI-CD and UEFI-USB
{
# This is just boilerplate I insert to all my bash scripts
set -e
set -u
set -o pipefail
shopt -s inherit_errexit
shopt -s nullglob
export LC_ALL=C.UTF-8
if [ $# != 1 ]; then
echo "Usage: ${0##*/} OUT" >&2
exit 1
fi
OUT="$1"
DIR="$(mktemp -d /tmp/grub-XX)"
mkdir -p "$DIR/esp/EFI/boot" "$DIR/esp/EFI/debian"
"$DIR/main-root/EFI/debian" "$DIR/main-root/boot/grub"
wget -O "$DIR/esp/EFI/boot/bootx64.efi"
'https://sources.debian.org/src/shim-signed/latest/shimx64.efi.signed/'
mv /tmp/grub.efi "$DIR/esp/EFI/boot/grubx64.efi"
cat << "EOF" > "$DIR/esp/EFI/debian/grub.cfg"
echo "This is /EFI/debian/grub.cfg from ESP"
echo "Testing shows that this file is loaded during UEFI-USB"
sleep 10
EOF
mkfs.vfat -C "$DIR/main-root/boot/grub/efi.img" 1
mcopy -s -i "$DIR/main-root/boot/grub/efi.img" "$DIR/esp/EFI" ::/
cat << "EOF" > "$DIR/main-root/EFI/debian/grub.cfg"
echo "This is /EFI/debian/grub.cfg from main file system (iso9660)"
echo "Testing shows that this file is loaded during UEFI-CD"
sleep 10
EOF
# I don't know why this "$DIR/main-root/zero" is needed. Anyway this is just
a demo
dd if=/dev/zero of="$DIR/main-root/zero" bs=1M count=1
xorriso -as mkisofs -b /zero -no-emul-boot --efi-boot /boot/grub/efi.img
-efi-boot-part --efi-boot-image -o "$OUT" -r "$DIR/main-root"
rm -r "$DIR"
exit 0
}
***
Then I booted resulting .iso file in Qemu running on my host (debian bookworm
x86_64) by this command:
***
qemu-system-x86_64 -enable-kvm -m 4096 -bios OVMF.fd -cdrom /tmp/dx/o.iso
***
Then in Qemu I saw text "This is /EFI/debian/grub.cfg from..." AND artifacts.
Then, after 10 seconds I saw GRUB command line without artifacts. All these
happened both with and without your patch, i. e. your patch doesn't fix
anything for me.
--
Askar Safin
https://types.pl/@safinaskar
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
