💾 Archived View for dioskouroi.xyz › thread › 24926384 captured on 2020-10-31 at 00:58:48. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
HN might like this wiki article I wrote titled “The BIOS/MBR boot process” which covers everything that happens (at some level) from when you press the power button to when your OS loads:
https://neosmart.net/wiki/mbr-boot-process/
It’s a bit of a higher level brain dump/crash course on boot info that I learned developing EasyBCD and EasyRE.
I’ve been meaning to write up an equivalent for UEFI/GPT which are far more complex in some ways but simpler in others for some years now, but haven’t found the motivation to do so (burnout really sucks).
I want the BIOS (or whatever we're calling it now) to do as little as possible. Find the OS, load it, transfer control to it, stop.
The most complex thing a BIOS should need to do is the user interface when I press F2 (or something) so I can boot from a DVD or USB.
I don't ever want to "upgrade" the BIOS. If I have a machine with suspected malware on the HDD, I want to be able to remove that hard disk and be reasonably confident that the machine is now malware-free. If the malware had a chance to replace the BIOS, I would need to open up the case and use additional equipment to put the BIOS code back, as I could not rely on the BIOS code to this task for me.
The problems are:
* "Show the user interface" implies that you need a way to render to the screen. Rendering to the screen implies a graphics driver. Since on many architectures the user can change the graphics hardware, you need a Plug&Play system where drivers for graphic cards can be loaded dynamically (e.g. from the PROM in the graphics card itself, and yes, EFI does this) . You need to be able to set resolutions, control multiple plugged in monitors (otherwise your BIOS output is sent to your HDMI connected projector only rather than your primary monitor).
* "when I press F2": to read keyboard input implies a full USB stack with HID support. Bluetooth keyboard? You need a USB stack again, HCI support, capability for storing non-volatile data such as the pairing key for the keyboard, and either the UI to pair stuff or at least a tool to edit the pairing information once the system is booted (likely not a hit with users).
* "Boot from a DVD" implies a Serial ATA stack, ATAPI possibly full SCSI stack. ISO9660 support, plus FAT32.
* "Boot from a USB" implies USB host support, likely USB 1, USB2/EHCI, and USB3/xHCI support -- unless you want your pendrive to work on some ports and not others, or some pendrives to work and not others. Also support for the multiple mass storage protocols such as Mass Storage or UAS (again, full SCSI stack), and support for FAT32, exFAT, likely NTFS since a lot of people use it, etc.
* And then comes the bells & whistles that most users also want, which suprisingly at this point actually add very little complexity. Fancy graphics support, mouse support (you already have HID driver, so why not?), sound support (cause most devices don't have a plain speaker anymore, if you want even simple beeps you have to use the sound card, which requires drivers like HDA, codec drivers, etc. And yes, Macs do this.), crypto functions for full disk encryption support, OPAL, secureboot, etc.
* Also most users want their BIOS to present devices in a abstract way, i.e. so that your kernel is able to render to a framebuffer on an ARM server board with the same code it uses to render to a framebuffer on more standarized x86.
All of this at this point already requires a operating system-level of complexity. So you end up with a BIOS that resembles an operating system -- EFI.
tldr: BIOS are complicated because they have to abstract hardware, and hardware has become complicated.
_"Show the user interface" implies that you need a way to render to the screen. Rendering to the screen implies a graphics driver._
VGA text mode should always be available.
_You need to be able to set resolutions, control multiple plugged in monitors (otherwise your BIOS output is sent to your HDMI connected projector only rather than your primary monitor)._
Sane defaults help a lot here --- like all outputs enabled (and showing the same thing), and of course 80x25 text mode.
_and support for FAT32, exFAT, likely NTFS since a lot of people use it, etc._
Load first sector of boot device to 7c00h and jump to it. The code there can use int 13h to load the rest. BIOS doesn't need to have _any_ knowledge of the filesystem to do that, nor should it.
_Also most users want their BIOS to present devices in a abstract way, i.e. so that your kernel is able to render to a framebuffer on an ARM server board with the same code it uses to render to a framebuffer on more standarized x86._
Approximately zero users care about ARM having the same BIOS as x86.
_and hardware has become complicated._
Not all of that complication is necessary, however. USB and ATAPI boot, as well as PXE (network boot) was been around long before UEFI reared its ugly head. I bet the amount of space taken up by the (IMHO totally unnecessary and definitely not wanted if you're in the CMOS SETUP to fix something with the GPU not working right) graphics in UEFI setup is far more than an entire pre-UEFI BIOS with all the other features.
> VGA text mode should always be available.
Surprise: it's not. Even on PC hardware there are cards right now that will not render VGA modes correctly, or on all monitors. And what if you have two VGA cards? It's more common these days to have two VGA cards rather than one, and you simply have no way to use two cards simultaneously with standard PC VGA.
> Not all of that complication is necessary, however.
Sure, but it is there, and the dream of going back to a platform where everything is standarized at the IO register level is just wishful thinking.
Fair points. I'll accept the F2 interface only working on a standard keyboard with a basic monitor port and a restricted selection of USB devices. Needing to use it at all is an exceptional case that only techies need understand.
Sound, fancy graphics, mouse, disk encryption. These can all be delegated to the OS loaded from the hard disk. You don't need any of these in the BIOS.
The reason for wanting a simple BIOS is so it can be protected from being modified by malware. That's the prize. I'm not saying there won't be costs, but I think the benefits outweigh them significantly.
I've had my desktop machine for something like five years and its worked fine without ever needing a BIOS update. It can boot up a live-USB copy of Linux quite happily, but if I ever add a set of future-USB ports that the BIOS doesn't know about, I'll have to be content to using the old USB ports on the motherboard just to get the alt-OS started.
These are reasonable wants, but without technical justification they will be ignored for the same reason they were when UEFI was standardized.
Also, at least one of them is a customer complaint: “I don’t want to have to upgrade it”. You don’t have to. Your machine will always work fine and a continually updated OS will apply whatever patches are necessary, except if your BIOS is compromised.
Just to clarify, I want to not even be _able_ to upgrade the BIOS. The machine can't tell if I'm actually sitting there trying to push new code into the ROM or if some malware is doing it, so I want the machine to refuse any request.
Okay, maybe a hardware switch on the motherboard wired to the write-protect pin, but that begs the question of why that write-protect pin is needed. (Another comment expresses why which I'll respond to separately.)
_Okay, maybe a hardware switch on the motherboard wired to the write-protect pin, but that begs the question of why that write-protect pin is needed._
For a period in the late 90s and early 2000s, there was a physical write-protect. That was also a period when BIOSes came with less bugs, so there was far less need to change it; but when the need did arise, it was there.
> _Also, at least one of them is a customer complaint: “I don’t want to have to upgrade it”. You don’t have to. Your machine will always work fine and a continually updated OS will apply whatever patches are necessary, except if your BIOS is compromised._
"I don't want to have to upgrade my BIOS" shouldn't translate to the OS automatically applying updates to the BIOS. It should translate to the BIOS not needing an update in the first place.
UEFI needs to be on an SD card instead of them stupid SOIC-8 flash chips and easily physically replaceable.
Most desktops have a removable flash chip. For laptops, you can desolder the chip and run magnet wire outside the case. With a little work, you could attach the magnet wire to the SD cardreader contacts inside the case.
There are also chips with fuses you can blow to make them write once. Somewhere back in my comments is a link to a datasheet.
But all of that doesn't really matter, because OEM's don't ship firmware images with checksums or signatures.
UEFI I think is what the cool kids are calling it now, and after spending countless hours tearing into the bloody thing, I can't really argue against any aspect of it except for the way industry actors go out of their way to make it understandable, and certain use cases people may throw at it (remote attestation).
My only gripes with UEFI are the copyright concerns.
I'm not sure if it's legal to implement UEFI without being a member of the UEFI forum. I don't know if I should avoid reading the spec so that my work doesn't become tainted, etc.
Of course, in order to generally make use of more than 4 GiB of RAM, a 64-bit OS is also needed. (Note: PCs with 32-bit OSs often show only about 3.2 to 3.3 GiB available when 4 GiB is installed, since addressable hardware; especially onboard video controllers, may use hundreds of MB for their own support.)
Pentium Pro from 1995 could address up to 64 GB RAM. As could the most Intel CPUs after that release.
Of course you still get only 4 GB virtual address space per process in a 32-bit system. That also includes I/O memory mapped ranges, like a graphics card aperture. Different processes can have different sets of 4 GB mapped to them.
Yeah, the issue with Windows 32-bits showing "3.3GB available" is another MS political/licensing decision. PAE as a technology is decades old.
Windows 32-bits _server_ editions have no problem showing and using 64GB of RAM, and you hack licensing checks on workstation editions to do that too.
There is a way around this limitation on consumer versions of Windows. There's a patch by Wen Jia Liu and it works even to this day on the very latest build of Windows 10 (20H2).
https://wj32.org/wp/2016/02/01/pae-patch-updated-for-windows...
Granted, in 2020, I can't imagine why you'd still want to run a 32-bit version of Windows these days outside of select scenarios, like IoT or embedded systems.
"Granted, in 2020, I can't imagine why you'd still want to run a 32-bit version of Windows these days outside of select scenarios, like IoT or embedded systems."
There is a ton of old hardware and software that only supports 32-bit Windows for a reason or another. So some organizations are perpetually stuck to it.
Then there are those who are still running 2000 or XP. Or even DOS...