On 11/06/2024 14:03, Eric J Bowman via illumos-discuss wrote:
> > oops, 4k FAT32 minimum size is about 256MB:) >
For Windows, the minimum size is 260 MB: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11
If that's your blocksize. I'm sector-aligning a partition containing a fs with 512b formatting. ;-)/EFI/boot/loader*.efi is a Windows PE for MS-DOS PXE, I'd rather not tightly couple my OS to Windows ways. Most folks assume PXE=MS-DOS but that's an implementation detail not an UEFI requirement. Secure Boot my way, would require developing the tools for managing keys and whatnot, but those binaries would be Zig (which can target its builds for Windows PE, as opposed to using EDK2). Zig ought to be able to build lightty.efi either way. Building for the same native environment as the FICL runtime, would allow Forth to be used as the httpd configuration language.-Eric---- On Tue, 11 Jun 2024 03:24:49 -0700 *Toomas Soome via illumos-discuss <[email protected]>* wrote ---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-M1eb5ec1d9bd2ddbf9e3b5706>
OpenPGP_0x8F3115112EB8DB54.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
<<< multipart/mixed; boundary=------------hdC0s35zglBJlVLfQ0By3Uue; protected-headers=v1; boundary="----------=_1718111869-313104-1"; charset="UTF-8": Unrecognized >>>
