The Oft-Rumored Death of UEFI's CSM Prophesied Again by Intel

Sometimes I feel like discussions about the death of the CSM (and thus legacy OS support in BIOS) to be somewhat akin to prophesying the return of Christ.  This has been the promise of UEFI since it was just a gleam in Intel's Itanium eye. Now Intel has publicly stated that they will not provide the related silicon pieces needed for delivering CSM in BIOS, starting with platforms that ship in 2020. The CSM (Compatibility Support Module) is the portion of the UEFI BIOS that delivers support for older operating systems, including DOS  and (surprisingly), Windows 7. The 16-bit x86 assembly looks sort of like someone took a 90's era BIOS, gutted it and attached the limbs to the UEFI torso.

[1]

For those of you keeping track, that would be two chipset generations from the current Cannon Lake/Coffee Lake generation. This would include legacy option ROMs for devices like video, NIC, RAID and ME as well as various testing and manufacturing tools that run under DOS (which relies on the CSM).

Windows 7 is a big sticking point, since was the last version (before Windows 10) adopted by many companies as their standard install version. But DOS is a hidden requirement that few people know or talk about, because they don't use DOS, but the manufacturers do, when they are building, testing and shipping the box.  

Why DOS? First, it is a low-overhead environment, putting few barriers between a testing or diagnostic application and the hardware. Second, it is free, in its FreeDOS incarnation. Third, because they have years of experience using it, with scripts, test tools and processes all built around it. Changes in this area introduces risk on the manufacturing line, and computer makers are risk-averse.

Intel would like to replace DOS with the UEFI Shell. It has many of the same intrinsic features (free, low hardware requirements). My feeling is that the UEFI shell is a great idea, but a lot of recent effort has ignored improving the built-in shell commands in favor of trying to support Python (see, AppPkg's Python port or more recent efforts to support MicroPython). Python is great, but I think that a little more work to port some command-prompt standards like printf and diskpart or ?.

What will it mean for BIOS manufacturers if the CSM and support for legacy OSes is removed? Certainly the fact that we don't have to test and validate tons of older, out-of-support OSes. Also, there is a lot of code for handling the "dual-boot" options that appear in setup. That is, we permit the user to choose legacy boot, UEFI boot, or auto-detect.  This adds a lot of complexity throughout the boot code.  Get rid of that and we can simplify. The other big area is hardware support. Even as new hardware standards, like USB-3 and NVMe have come along, support for these devices had to be added to the CSM, even though the CSM was never designed to support this. Oh, and we don't want to duplicate code, which has often caused code to be pushed into SMM so that it can be shared between legacy and UEFI OS. All of these to a simplification of the BIOS code and the effort required to validate it.

On the other hand, BIOS has always been the last bastion of compatibility with older standards. As I've often said, BIOS is where industry standards go to die...and then they stink. Anyone remember EISA, QEMM (not QEMU!) and using Flight Simulator as a BIOS test? The CSM was one of the pieces of firmware that was hard to reproduce in BIOS-something that forced people to talk to us, because there are few software companies with the necessary 30 year histories to remember why we did certain things. What will we do now?

That is the question, isn't it? What will we do now? Dang, now that we don't need to do CSM, we actually have time to do some more innovation! So, go on, let it die.

[1] "Last Mile" Barriers to Removing Legacy BIOS Fall 2017 UEFI Plugfest (October 2017), Brian Richardson (Intel Corporation) retrieved from http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf on 4/21/2018.