3 ms·

When we talk about these sector$LANG implementations, I am guessing we are talking about the boot sector that BIOS recognizes, right? Does the 512 byte limit f

by distcs 3y ago

When we talk about these sector$LANG implementations, I am guessing we are talking about the boot sector that BIOS recognizes, right? Does the 512 byte limit for a boot sector exist in UEFI too? I don't know much about UEFI so if someone could educate me about how the boot sector and its size limit differs in UEFI, I'd love to know.

sspiff 3y ago
No, UEFI loads PE executables from a special partition called the EFI System Partition or ESP. There's no real size restriction there as far as I know. Before the ESP is accessed, there is no standardized way to customize the boot process. You could put these kinds of sectorX toys into the firmware directly, which would come with more constraints, but it would be vendor-specific. There is a platform-independent VM running a special EFI byte code that is part of the EFI specification, which allows you to extend the UEFI system with things like additional drivers, but those are also loaded from the ESP.
- oynqr 3y ago
  Since FAT32 is the only FS that must be supported, I'd guess one potential limit is 4 gigs.
  - sspiff 3y ago
    It's not exactly FAT32, but close enough. I don't know if they provide any way to bypass the 4GB limit, but I doubt it. Still, that would be 4GB per file, and UEFI provides a file system access interface, so you could easily load in more.
- distcs 3y ago
  Thanks for the answer! I've got some more questions now. Sorry, but if anyone is willing to take a stab at these questions, it'd be helpful to me. 1. IIUC PE executables are Windows executables. So a Linux system that targets UEFI ends up writing a PE executable to the EFI System Partition? 2. I know that some UEFIs (or is it all?) support BIOS boot sector as backward compatibility feature? How does that work? If I write a "hello world" program in pure machine code in the 1st sector of the boot disk, would UEFI read that and execute that? How would it even know whether what's in the first sector is valid code or garbage? By checking the magic 0x55 0xaa at the end of the boot sector?
  - rft 3y ago
    > 1. IIUC PE executables are Windows executables. So a Linux system that targets UEFI ends up writing a PE executable to the EFI System Partition? Short answer: Yes. Longer answer: Yes, but it is not exactly a classic Windows desktop application. A PE file itself is at its core just a way to store data in a somewhat structured way. It has metadata (like imports/exports and the target architecture) and actual contents (like data and code). I think it is a good idea to reuse an already existing, common executable file format for this use case. That the choice was PE instead of ELF or Mach-O is, IMO, the result of Microsoft being in the UEFI consortium. They are a big player and likely pushed for this. Whether or not ELF would have been a better choice, I can not say, but at this point I don't think it matters. More info on that topic at OSDev Wiki: https://wiki.osdev.org/UEFI#Binary_Format https://wiki.osdev.org/UEFI#Binary_Format File output on my GRUB install: /boot/EFI/GRUB/grubx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows, 4 sections
    - Brian_K_White 3y ago
      "I think it is a good idea to reuse an already existing, common executable file format for this use case." Similarly how many file formats are actually just pkzip files with standardzied names and contents.
  - sspiff 3y ago
    1. Yes, that's exactly right. It installs a GRUB version compiled into a PE executable, typically. 2. Boot sector support requires UEFI CSM support, which most PCs have (but ARM based devices and Intel Macs don't). With the deprecation of 32-bit architectures in a lot of operating systems, some vendors also started dropping CSM support in some devices, but most devices still ship with CSM either enabled by default or as an option in the settings.
danbruc 3y ago
A classical PC master boot record does not actually have 512 byte for code as it also contains the partition table and a signature, you have 446 bytes for code. Not sure what exactly the BIOS validates, you might be able to get away with an invalid partition table. In general there is not really any limit unless you want to be compatible with something existing, you can define whatever disk layout you like. At worst you will have to load additional sectors yourself because the BIOS has no clue where you put them. I no longer remember what a floppy boot sector looks like, how much room you have there.

by distcs 3y ago

sspiff 3y ago

No, UEFI loads PE executables from a special partition called the EFI System Partition or ESP. There's no real size restriction there as far as I know. Before the ESP is accessed, there is no standardized way to customize the boot process. You could put these kinds of sectorX toys into the firmware directly, which would come with more constraints, but it would be vendor-specific. There is a platform-independent VM running a special EFI byte code that is part of the EFI specification, which allows you to extend the UEFI system with things like additional drivers, but those are also loaded from the ESP.

oynqr 3y ago
Since FAT32 is the only FS that must be supported, I'd guess one potential limit is 4 gigs.
- sspiff 3y ago
  It's not exactly FAT32, but close enough. I don't know if they provide any way to bypass the 4GB limit, but I doubt it. Still, that would be 4GB per file, and UEFI provides a file system access interface, so you could easily load in more.
distcs 3y ago
Thanks for the answer! I've got some more questions now. Sorry, but if anyone is willing to take a stab at these questions, it'd be helpful to me. 1. IIUC PE executables are Windows executables. So a Linux system that targets UEFI ends up writing a PE executable to the EFI System Partition? 2. I know that some UEFIs (or is it all?) support BIOS boot sector as backward compatibility feature? How does that work? If I write a "hello world" program in pure machine code in the 1st sector of the boot disk, would UEFI read that and execute that? How would it even know whether what's in the first sector is valid code or garbage? By checking the magic 0x55 0xaa at the end of the boot sector?
- rft 3y ago
  > 1. IIUC PE executables are Windows executables. So a Linux system that targets UEFI ends up writing a PE executable to the EFI System Partition? Short answer: Yes. Longer answer: Yes, but it is not exactly a classic Windows desktop application. A PE file itself is at its core just a way to store data in a somewhat structured way. It has metadata (like imports/exports and the target architecture) and actual contents (like data and code). I think it is a good idea to reuse an already existing, common executable file format for this use case. That the choice was PE instead of ELF or Mach-O is, IMO, the result of Microsoft being in the UEFI consortium. They are a big player and likely pushed for this. Whether or not ELF would have been a better choice, I can not say, but at this point I don't think it matters. More info on that topic at OSDev Wiki: https://wiki.osdev.org/UEFI#Binary_Format https://wiki.osdev.org/UEFI#Binary_Format File output on my GRUB install: /boot/EFI/GRUB/grubx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows, 4 sections
  - Brian_K_White 3y ago
    "I think it is a good idea to reuse an already existing, common executable file format for this use case." Similarly how many file formats are actually just pkzip files with standardzied names and contents.
- sspiff 3y ago
  1. Yes, that's exactly right. It installs a GRUB version compiled into a PE executable, typically. 2. Boot sector support requires UEFI CSM support, which most PCs have (but ARM based devices and Intel Macs don't). With the deprecation of 32-bit architectures in a lot of operating systems, some vendors also started dropping CSM support in some devices, but most devices still ship with CSM either enabled by default or as an option in the settings.

danbruc 3y ago

A classical PC master boot record does not actually have 512 byte for code as it also contains the partition table and a signature, you have 446 bytes for code. Not sure what exactly the BIOS validates, you might be able to get away with an invalid partition table. In general there is not really any limit unless you want to be compatible with something existing, you can define whatever disk layout you like. At worst you will have to load additional sectors yourself because the BIOS has no clue where you put them. I no longer remember what a floppy boot sector looks like, how much room you have there.