> On 11. Jun 2024, at 12:05, Toomas Soome via illumos-discuss > <[email protected]> wrote: > > > >> On 11. Jun 2024, at 04:05, Eric J Bowman via illumos-discuss >> <[email protected]> wrote: >> >> Having re-re-read UEFI, UEFI*, and UEFI*(*), the title represents my >> takeaway. >> >> I felt right at home earlier this year when I installed a Fedora for the >> first time ever. DnfDrake is exactly the same hideous UI I have three >> decades of experience with, on my SGI Indy MIPS R5000 IRIX box. The only >> copies of Photoshop and Illustrator I apparently actually own, are the v3 >> R5K SGI house-hotrodded-for-IRIX I can now only ssh -X into, on a Motif CDE >> which uses ELF packages and RPM. The rest of the system is SVR4 packages and >> pkgsrc, this is still the factory install, patched until there were no more >> patches. >> >> The machine has 64MB RAM and a 2GB SCSI-2 drive with proprietary SGI >> terminator interface, dual HDD's were not an option, this drive is now >> irreplaceable to the point it's why I'm afraid to power up the system, and >> what I really want is an SGI-branded IRIX zone so I can see how well my >> Adobe products work without the resource limitations imposed by hardware >> that was ahead of the game in its day. >> >> Closing in on 30 years of XFS without so much as a hiccup. No wonder UEFI >> (no-*) recommends XFS for PXE! I couldn't agree more. >> >> What UEFI has to say about ESP sizing is, "big enough for your bootloader, >> duh" and some fs's are OK with UEFI's 1 MiB minimum (which is half wrong). >> Others, fat32 and XFS included, need to support both the encrypted and >> unencrypted use cases. As the encryption requires 32 MiBs and unencrypted at >> least 1 MiB, the fs's both require a 33 MiB minimum, and this is why my >> advice for ESP sizing is 64 MiB, not 32 MiB or lower. >> > > > In fact, UEFI spec does not say anything about the ESP size. The values used > for ESP size are coming from 2 sources: > > 1. file system type, stated in UEFI specification as: > "FAT File System The file system on which the EFI File system is based. See > File Allocation Table (FAT) and GUID Partition Table (GPT).” > > As we know, there are FAT12, FAT16 and FAT32, where FAT12/FAT16 are/were > intendet to be used on removable media and FAT32 on hdd; the UEFI > specification by itself is not stating which one is to be supported by > firmware, so there is a zoo - some systems do support all FAT types, some > only do support FAT32 for HDD. And therefore the *minimum* ESP size depends > on file system specification — for example, 4k sector size FAT32 minimum size > is about 25
oops, 4k FAT32 minimum size is about 256MB:) rgds, toomas > > 2. OS vendor suggestion - while boot loader itself is relatively small, OS > vendors (like Microsoft) are suggesting to allocate specific “minimum” sizes > to be able to store additional applications, like diagnostic tools and > firmware update tools. > > >> UEFI* says i386 firmware, as implemented and allowed, looks for /EFI in a >> fat32 ESP, while allowing multiple ESPs to share a drive. >> >> UEFI*(*) supports my 320MiB (as required by whatever Fedora's installer is >> called) MS-DOS PXE's (label=BOOTER) fallback bootloader's loading a r/o GRUB >> xfs.efi driver, before scanning the other ESP (LOADER) for /EFI/boot/*.efi >> and doesn't care if it isn't a Windows PE binary. >> >> So, loader.efi can = loader.4th, seeing as how loader64.efi's a subset of cc >> which supports FICL, and *that's* what's compiled as a wrapper around >> loader.4th. What else is a tiny cc which covers the subset FICL requires? > > the loader64.efi and loader are only similar as we do try to provide feature > compatibility and we are doing this by using shared code. FICL there is > essentially just about providing command line interpreter and scripting > engine (+ being forth implementation, it can provide access to the machine in > a ways that other languages can not do;) however, loader64.efi is using UEFI > API and loader is using BIOS API, so those two can not be mixed in any way. > Once BIOS is [declared] dead, we can just drop BIOS specific loader (and its > auxiliary components). > > >> >> Zig. >> >> So, the only reason to make loader.efi have anything to do with MS-DOS is if >> you need to get your ticket punched for entry to Microsoft Security Theatre, >> which has UEFI as a dependency, but this is not reciprocal. > > loader.efi has nothing to do about MS-DOS:) > >> >> Which means, we can solve UEFI Secure Boot *and* implement CRC to avoid the >> hole I blamed UEFI for falling bass-ackwards into. Because we can code that >> bit in Zig and configure it with 4th and have ONE unified bootloader on i386 >> for any # of boot scenarios involving a FICL-booted OS, *and* it's a UEFI 2+ >> compatible software boot manager like rEFInd. Which is the catch, making it >> work on i386 requires a Windows PE boot manager, but the fallback bootloader >> and shim.efi and all that applies to *.efi not MS-DOS. >> > > i386 in [illumos] loader context means either 32-bit BIOS loader and its > auxiliary components (pmbr, gptxfsboot, pxeboot, cdboot, isoboot) or > loader32.efi (which is used by systems implementing 32-bit UEFI). Noting this > just to be sure we are on the same page regarding to terminology. > > Secure boot by itself is about definition. Technically we can build signed > binary of bootloader and add support some special features (like > authenticated access to variables etc), to to this, one needs infrastructure > for key management and related policies. > > Other part of the story is, how far your “secure boot” should go, is it just > about bootloader (and bootloader scripts)? Or kernel? or loadable modules? Or > verified userspace applications and libraries? > > rgds, > toomas > >> The trick I don't have time to work out, and I'm a noob with Zig who's only >> just begun working on "zmake config", is how to make its runtime BE the PXE. >> What I'm using as my test code for building zmake is lighttpd, straight-up >> POSIX C, and modular so I can leave out everything that isn't HTTP 1.1 >> pipelining and... use it to pixie-boot an OS installed in a local partition, >> on another system. >> >> -Eric >> >> > > illumos <https://illumos.topicbox.com/latest> / illumos-discuss / see > discussions <https://illumos.topicbox.com/groups/discuss> + participants > <https://illumos.topicbox.com/groups/discuss/members> + delivery options > <https://illumos.topicbox.com/groups/discuss/subscription>Permalink > <https://illumos.topicbox.com/groups/discuss/Tead303addea2207e-M28e8610d05833e3ce8a7ad24> ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tead303addea2207e-M2337ab34fbffeabd32b8a4be Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
