Date: Mon, 22 Feb 2021 19:01:44 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 253770] Unified Linux Kernel Images (EFI-STUB) crash when chain-loaded by FreeBSD loader Message-ID: <bug-253770-99@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253770 Bug ID: 253770 Summary: Unified Linux Kernel Images (EFI-STUB) crash when chain-loaded by FreeBSD loader Product: Base System Version: 13.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: standards Assignee: standards@FreeBSD.org Reporter: schreiberstein@gmail.com Attachment #222729 text/plain mime type: Created attachment 222729 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D222729&action= =3Dedit Linux Bash script to generate the unified kernel images for testing with FreeBSD loader - PROBLEM A unified Linux kernel image built with systemd's EFI STUB is currently (systemd v247, FreeBSD 13 BETA3) unable to be chain-loaded by FreeBSD's nat= ive bootloader "loader". - SYSTEM I have tested this on a VMware virtual machine's UEFI environment. - STEPS TO REPRODUCE 1. Prepare artifacts by running [reproduce_artifacts.sh] on a recent GNU/Li= nux machine (depends on bash, zstd, base64, gzip, objcopy, sha1sum) 2. Download latest FreeBSD 13 disc1 iso image (tested with BETA3) 3. Install FreeBSD 13 via UEFI mode (select "Guided ZFS" and "GPT" and enab= le SSH) 4. Boot into system 5. Copy both [unified-upstream.efi] and [unified-patched.efi] artifacts to = the FreeBSD's [/boot/] folder via SSH 6. Reboot the machine 7. At loader prompt, press [3] to drop into loader shell 8. Execute the previously generated upstream unified kernel image by enteri= ng [chain /boot/unified-upstream.efi] The attached Bash script [reproduce_artifacts.sh] can be used to generate t= wo different unified kernel images consisting of the Debian GNU/Linux installer kernel and ramdisk, one using the upstream stub and one using the patched s= tub that utilized the workaround described below. ([unified-upstream.efi] and [unified-patched.efi]) (The patched stub variant is stored in the shell file via base64 encoding.) - EXPECTED BEHAVIOR Unified linux kernel image with embedded Debian GNU/Linux installer starts properly. - OBSERVED BEHAVIOR After the loading process of the EFI binary completes, the system hangs completely. - WORKAROUND According to FreeBSD's manpage regarding UEFI, it is noted as caveat that "= EFI environment variables are not supported by loader(8) or the kernel." Source: https://www.freebsd.org/cgi/man.cgi?query=3Duefi&sektion=3D8&manpath=3DFree= BSD+13.0-current This lead me to believe that the problem could be circumvented by removing practically all lines from systemd's [stub.c] that had to do with reading or setting EFI environment variables. The patch I created [systemd-v247-efi-stub-freebsd-loader-workaround.patch] radically removes all the potentially offending lines, adds two convenient debug messages and finally allowed me to successfully chainload unified ker= nel images via FreeBSD's loader. (I am aware that systemd code is not relevant = for FreeBSD, but I think it may serve as an indicator what kind of firmware cal= ls are being executed.) This is a workaround for this particular situation, not a solution. This radical approach is obviously not acceptable to be incorporated into t= he upstream stub, given that there are assumingly significantly more users interested in proper EFI variables than in booting via the FreeBSD loader - APPLICATION (OFF-TOPIC) I am developing a GNU/Linux based embedded system that consists of a single, self-contained (e.g. 500+ MB SquashFS ramdisk), highly compressed unified U= EFI amd64 kernel image binary. The embedded system utilizes its own storage / auto-provisioning software w= hich relies heavily on OpenZFS. Since OpenZFS is a first-class citizen in the FreeBSD world and other third-party bootloaders (GRUB, rEFInd, ...) appear to offer only limited ZFS support (+ problematic GPLv3 licensing), transplanting FreeBSD's bootloader= and using it to chainload unified kernel images seems like a reasonable choice. This approach enables the user to place unified kernel images on a (perhaps RAID-enabled) ZFS pool dataset and have them chain-loaded. Compared to storing them directly on the FAT32 ESP partition, this ensures = the integrity of the images in case of a sudden loss of power (e.g. during a software update), avoids tricky MDRAID/LVM based configurations and also removes the need to manually sync ESP partition content on multiple drives = when RAID is not used. I have not been able to find resources about people attempting to use FreeB= SD's loader to conveniently and reliably boot their OpenZFS-based GNU/Linux machines, but I personally think it would be a great alternative compared to what is available right now. - QUESTION I have previously filled an issue report with the systemd project and got t= he recommendation to get in touch with people from the FreeBSD project (=3D "not-our- bug"). Right now, it appears as if certain EFI variables get drop= ped while chain-loading and thus result in the EFI stub not working correctly. = When I comment out all lines that deal with EFI variable reading / setting, the = stub works as expected. The unified kernel image made with the upstream stub wor= ks flawlessly when being launched via an UEFI shell, iPXE or virtually any oth= er UEFI loader. You may view this issue here: https://github.com/systemd/systemd/issues/187= 33 (The patch to systemd may be retrieved on that page as well: https://github.com/systemd/systemd/files/6023017/patch_and_script.tar.gz) (If any of you do not have a GNU/Linux system handy, I may send / upload the EFI files resulting from that script elsewhere upon your request.) Is there something you can do about this problem? Thank you very much! Cheers, schreiberstein --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253770-99>