* Zig PXE for FICL w/ XFS
@ 2024-06-11 1:05 Eric J Bowman
2024-06-11 9:05 ` [discuss] " Toomas Soome
0 siblings, 1 reply; 7+ messages in thread
From: Eric J Bowman @ 2024-06-11 1:05 UTC (permalink / raw)
To: illumos-discuss
[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]
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.
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?
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.
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.
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
[-- Attachment #2: Type: text/html, Size: 3960 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [discuss] Zig PXE for FICL w/ XFS
2024-06-11 1:05 Zig PXE for FICL w/ XFS Eric J Bowman
@ 2024-06-11 9:05 ` Toomas Soome
2024-06-11 10:24 ` Toomas Soome
0 siblings, 1 reply; 7+ messages in thread
From: Toomas Soome @ 2024-06-11 9:05 UTC (permalink / raw)
To: illumos-discuss
[-- Attachment #1: Type: text/plain, Size: 6319 bytes --]
> On 11. Jun 2024, at 04:05, Eric J Bowman via illumos-discuss <discuss@lists.illumos.org> 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
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-M7b20da4cd5cb2b6c07ac7564>
[-- Attachment #2: Type: text/html, Size: 8689 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [discuss] Zig PXE for FICL w/ XFS
2024-06-11 9:05 ` [discuss] " Toomas Soome
@ 2024-06-11 10:24 ` Toomas Soome
2024-06-11 13:03 ` Eric J Bowman
0 siblings, 1 reply; 7+ messages in thread
From: Toomas Soome @ 2024-06-11 10:24 UTC (permalink / raw)
To: illumos-discuss
[-- Attachment #1: Type: text/plain, Size: 6587 bytes --]
> On 11. Jun 2024, at 12:05, Toomas Soome via illumos-discuss <discuss@lists.illumos.org> wrote:
>
>
>
>> On 11. Jun 2024, at 04:05, Eric J Bowman via illumos-discuss <discuss@lists.illumos.org> 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>
[-- Attachment #2: Type: text/html, Size: 9396 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [discuss] Zig PXE for FICL w/ XFS
2024-06-11 10:24 ` Toomas Soome
@ 2024-06-11 13:03 ` Eric J Bowman
2024-06-11 13:17 ` John Connett
0 siblings, 1 reply; 7+ messages in thread
From: Eric J Bowman @ 2024-06-11 13:03 UTC (permalink / raw)
To: illumos-discuss
[-- Attachment #1: Type: text/plain, Size: 7434 bytes --]
>
> oops, 4k FAT32 minimum size is about 256MB:)
>
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 <discuss@lists.illumos.org> wrote ---
On 11. Jun 2024, at 12:05, Toomas Soome via illumos-discuss <mailto:discuss@lists.illumos.org> wrote:
On 11. Jun 2024, at 04:05, Eric J Bowman via illumos-discuss <mailto:discuss@lists.illumos.org> 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
https://illumos.topicbox.com/latest / illumos-discuss / see https://illumos.topicbox.com/groups/discuss + https://illumos.topicbox.com/groups/discuss/members + https://illumos.topicbox.com/groups/discuss/subscription https://illumos.topicbox.com/groups/discuss/Tead303addea2207e-M2337ab34fbffeabd32b8a4be
[-- Attachment #2: Type: text/html, Size: 11121 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [discuss] Zig PXE for FICL w/ XFS
2024-06-11 13:03 ` Eric J Bowman
@ 2024-06-11 13:17 ` John Connett
2024-06-11 13:30 ` Eric J Bowman
2024-06-11 20:34 ` John D Groenveld
0 siblings, 2 replies; 7+ messages in thread
From: John Connett @ 2024-06-11 13:17 UTC (permalink / raw)
To: discuss
[-- Attachment #1.1.1.1: Type: text/plain, Size: 9211 bytes --]
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 <discuss@lists.illumos.org>* wrote ---
>
>
>
> On 11. Jun 2024, at 12:05, Toomas Soome via illumos-discuss
> <discuss@lists.illumos.org> wrote:
>
>
>
> On 11. Jun 2024, at 04:05, Eric J Bowman via
> illumos-discuss <discuss@lists.illumos.org> 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>
>
[-- Attachment #1.1.1.2: Type: text/html, Size: 23363 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 1771 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 505 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [discuss] Zig PXE for FICL w/ XFS
2024-06-11 13:17 ` John Connett
@ 2024-06-11 13:30 ` Eric J Bowman
2024-06-11 20:34 ` John D Groenveld
1 sibling, 0 replies; 7+ messages in thread
From: Eric J Bowman @ 2024-06-11 13:30 UTC (permalink / raw)
To: illumos-discuss
[-- Attachment #1: Type: text/plain, Size: 13592 bytes --]
That's Windows 10, and was really only that small if you are "in the club" and have automated install, in which case you were still set for Windows 8, and Windows 11 "health check" will say your system is incompatible, without saying the reason is not having a 300MiB ESP. Or something, I'm doing my best to forget Windows. Or at least never run it bare-metal again, but here's the problem, zones are portable and if you move Linux and Windows guests around (to a different pool, or just re-organize them) you need to hit the ZFS "tuneables" and figure out your new offsets because that'll depend on blocksize, and you'll also need to consider the offsets for talking to other zones in the pool which might have their alignment at 8K in a 16K blocksize pool.
Or, you can align partitions to 64K and avoid the nightmare of ZFS performance dropoff when the offsets are wrong, because all offsets are zero.
-Eric
---- On Tue, 11 Jun 2024 06:17:34 -0700 John Connett via illumos-discuss <discuss@lists.illumos.org> wrote ---
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 mailto:discuss@lists.illumos.org wrote ---
On 11. Jun 2024, at 12:05, Toomas Soome via
illumos-discuss <mailto:discuss@lists.illumos.org>
wrote:
On 11. Jun 2024, at 04:05, Eric J Bowman
via illumos-discuss <mailto:discuss@lists.illumos.org>
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
https://illumos.topicbox.com/latest /
illumos-discuss / see https://illumos.topicbox.com/groups/discuss + https://illumos.topicbox.com/groups/discuss/members + https://illumos.topicbox.com/groups/discuss/subscription https://illumos.topicbox.com/groups/discuss/Tead303addea2207e-M1eb5ec1d9bd2ddbf9e3b5706
[-- Attachment #2: Type: text/html, Size: 18236 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [discuss] Zig PXE for FICL w/ XFS
2024-06-11 13:17 ` John Connett
2024-06-11 13:30 ` Eric J Bowman
@ 2024-06-11 20:34 ` John D Groenveld
1 sibling, 0 replies; 7+ messages in thread
From: John D Groenveld @ 2024-06-11 20:34 UTC (permalink / raw)
To: illumos-discuss
In message <de922ea5-1032-40ba-88c0-8c1567e2f45d@skylon.me.uk>, "John Connett via illumos-discuss" writes:
>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
# gpart show
=> 40 488397088 ada0 GPT (233G)
40 409600 1 efi (200M)
409640 487987488 2 freebsd-zfs (233G)
=> 34 134217661 zvol/zroot/win10 GPT (64G)
34 2014 - free - (1.0M)
2048 204800 1 efi (100M)
206848 32768 2 ms-reserved (16M)
239616 132938464 3 ms-basic-data (63G)
133178080 1312 - free - (656K)
133179392 1034240 4 ms-recovery (505M)
134213632 4063 - free - (2.0M)
I haven't tried updating the bhyve VM to Window 11 yet.
Its cool that FreeBSD gpart(8) interrogates zvols for partition
tables; I haven't figured out how to convince illumos format(8)
to do the same.
John
groenveld@acm.org
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-06-11 20:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-11 1:05 Zig PXE for FICL w/ XFS Eric J Bowman
2024-06-11 9:05 ` [discuss] " Toomas Soome
2024-06-11 10:24 ` Toomas Soome
2024-06-11 13:03 ` Eric J Bowman
2024-06-11 13:17 ` John Connett
2024-06-11 13:30 ` Eric J Bowman
2024-06-11 20:34 ` John D Groenveld
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).