Peter Bright 11/22/2017 4:50 pm Categories:Tech View non-AMP version at arstechnica.com
The original IBM PC.
Ruben de Rijcke
Speaking at UEFI Plugfest, a hardware interoperability testing event held by the Unified Extensible Firmware Interface (UEFI) Forum earlier this month, Intel announced that by 2020 it was going to phase out the last remaining relics of the PC BIOS by 2020, marking the full transition to UEFI firmware.
The BIOS ("Basic Input/Output System") is a small piece of code embedded into a PC's motherboard that handles the basic initialization and booting of hardware. It's the BIOS that first probes your hardware, counts how much RAM you have installed, performs cursory checking of the hardware's health, and complains if your keyboard is unplugged; when it's finished doing its thing, it kicks off the process to actually load and run the operating system. When the operating system is running, the BIOS offers some basic system services, such as receiving keyboard input and reading and writing to the screen and the disk.
The BIOS was an essential element of IBM's first PC, the Personal Computer, in 1981. Companies wanting to build systems compatible with the PC had to build systems with a compatible BIOS, offering the same range of system services to software. If they could do this, software built for the PC would run seamlessly on their machines. Early PC clones companies each had to reverse engineered the BIOS themselves and didn't always do a great job of compatibility. But within a few years firmware company Phoenix had a reliable, accurate reverse-engineered BIOS, and it licensed it to third parties; this allowed PC clone production to proliferate.
IBM's PC BIOS was inextricably linked to the Intel x86 processors it ran on. It ran using the processor's 16-bit real mode, with the firmware itself typically written in assembler.
Over the years, the BIOS' services became less important. The use of 16-bit real mode meant that using BIOS functions was very slow, so as PC operating systems migrated in the 1990s to using the 32-bit protected mode introduced in the 386, they also started using their own 32-bit drivers to access hardware rather than the BIOS' system services. This relegated the BIOS to the initial system boot, with everything thereafter handled by the running OS.
That x86 coupling meant that other platforms, such as those built around Sun's SPARC chips and Apple/IBM/Motorola's PowerPC chips, had their own, incompatible firmwares. When Intel was developing and promoting its Itanium IA64 processors in the early 2000s, it needed a new firmware, as the x86 BIOS was obviously unsuitable. Rather than borrowing or extending one of the other non-x86 firmwares, the company developed EFI (Extensible Firmware Interface) for IA64 machines.
On x86 machines, however, the BIOS lingered on well into the 2000s. Eventually, the poor performance, limited functionality, and low maintainability made Intel and the rest of the PC industry look elsewhere. EFI was extended to support 32- and 64-bit x86 systems (and others; it's also found in many ARM machines, for example), at which point it gained its current name of UEFI.
PC operating system support started to materialize around 2007 (the 64-bit x86 version of Windows Vista Service Pack 1 introduced the ability to boot from UEFI). With Intel's Sandy Bridge generation of processors, introduced in 2011, PC hardware started switching in earnest to UEFI. Nowadays, UEFI is ubiquitous, and virtually all, if not all, x86 systems ship with UEFI and not BIOS.
And while hardware companies have been a little slow off the mark, they're starting to take advantage of UEFI's easier development. Certain Surface-branded hardware from Microsoft, for example, can perform bare metal operating system recovery and installation, direct from firmware, using nothing more than an Internet connection. Such a thing really wasn't practical with a BIOS. More widely, UEFI systems can boot a lot faster than BIOS ones.
If BIOS isn't being used any more, one might wonder just what Intel is planning to do by 2020. Presently, we're in a transitional period. Although all new hardware and operating systems work natively with UEFI, the use of older operating systems—DOS, 32-bit versions of Windows older than Windows 7, 64-bit versions of Windows older than Windows Vista—is non-negligible. Moreover, certain hardware devices are also tied to the BIOS. The old BIOS had an extensibility system called Option ROMs that enabled, for example, add-in disk controllers to be recognized by and programmed with the BIOS' system services. These Option ROMs are, like the BIOS themselves, written in 16-bit real mode x86 code.
Enlarge / Legacy-free by 2020.
Intel/UEFI Forum
First-generation UEFI firmware was written to exclusively offer BIOS-compatible programmatic interfaces, making it seamlessly compatible with this BIOS-demanding hardware and software. Later UEFI firmware offers UEFI-native interfaces. To handle these things—old operating systems that still expect to be booted by a BIOS and old hardware that still expects to extend a BIOS—these newer firmwares can operate in a BIOS-compatible mode with a thing called the Compatibility Support Module (CSM). With the CSM, modern systems can boot old software and support old hardware. Without it, only UEFI-native hardware and software will work.
Most PCs shipping today actually ship with the CSM disabled, though they can often have it enabled as an option. By contrast, a great many standalone motherboards for self-builders ship with the CSM enabled, and, likewise, they can have it disabled as an option. A big reason for this disparity is Secure Boot and the hardware requirements that Microsoft mandates in order for a piece of hardware to be qualified for a Windows logo. Secure Boot, which protects against a wide range of malicious software that depends on tampering with the operating system on-disk, can only operate with a CSM disabled. As such, most OEM PCs ship in the Windows logo-compliant, CSM-disabled mode. Self-builders typically don't care about such things, which is why motherboards ship in the more compatible, but less secure, CSM mode.
Intel's plan is to scrap the CSM entirely. This will simplify the hardware—no need to validate it with both CSM off and on—and will mean that developers of things such as new network cards, disk controllers, and video cards no longer need to offer legacy Option ROMs just in case someone is using brand-new hardware with ancient software. It will also firmly relegate that old software to virtual machines or other ways of mimicking old environments.
Looking forward, scrapping the CSM might also enable Intel to scrap other legacy tech. Even the very latest and greatest Intel processor, such as the monster $13,011, 28-core, 56-thread Xeon Platinum 8180M, boots up acting as if it's a 16-bit 8086 chip and still has all the ancient 16-bit processor modes. Take away the BIOS and CSM requirement and it might open the door to also removing these legacy processor modes.
There have been rumors that a future Intel x86 processor would scale back some of its legacy support; a pure 32- and 64-bit processor that dropped 16-bit compatibility would fit neatly with the plans to remove the last vestiges of the BIOS from UEFI.