20 Year Anniversary: The CIH Virus and the BIOS

As noted in this article, April 26th marked the anniversary when the CIH (or Chernobyl) virus would deliberately attack the contents of the flash chip containing the BIOS part on certain motherboards, making those systems inoperable. The write-protect line on the flash chip was easily disabled, if you knew the little-known access sequence. As the author correctly concludes, "Don't rely on security through obscurity." OEMs and BIOS vendors are sometimes guilty of assuming that BIOS code is so obscure that no one will bother. But in an era where the data on the computer is so much more valuable than the cost of disassembling (or purchasing!) the code, that is no longer a safe assumption. 

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.

Spring 2018 UEFI Plugfest Presentations Now Available

Head here to get the latest UEFI plugfest presentations on a variety of topics, although security dominates the topic list, with top notch presentations by Insyde, Intel (and here), ARM, Phoenix and Microsoft. The presentation by Microsoft is a redacted version of what was presented live because it contained details about unreleased versions of the Windows operating systems.

After security, it was programming languages, with presentations by Intel for ACPI Source Language (ASL) and MicroPython. 

My presentation focused on adapting Microsoft's Security Development Lifecycle to UEFI and firmware, based on our ongoing experience at Insyde. Conversations afterward showed a great level of interest in introducing these processes into an industry that has traditionally not worried about this level of discipline in security.

Rounding out the topic list was the state of UEFI (the illustrious Mark Doran, Intel), SMBIOS and ACPI table construction (ARM), EDK2 platforms (Linaro), UEFI capsule update (Microsoft), and NVMe (AMI).

Repository for the Misc. UEFI Code Posted Here

Just as a reminder, all of the code that's been posted here over time is checked in over at SourceForge here. No guarantees.

UEFI Notes: CS2AI, UEFI Plugfest and the Zimmer Anniversary Post

After some gentle ribbing from colleagues at the UEFI plug-fest in Bellevue, WA, I've decided to try to keep track of recent trends in UEFI here again.

My collaborator on the UEFI shell book, Vincent Zimmer has posted some thoughts on open source and open platforms in his anniversary blog post here. He has a long history within the UEFI community and is currently working to lower the barrier of entry to server firmware design. And for the record, it is U-E-F-I (not YOO-FI or micro-EFI) and A-C-P-I (not AK-PIE). On a side note about competing acronym pronunciations, in the early days of the EISA (Extended ISA) bus architecture, it was pointed out that while English speakers naturally pronounced EISA as EEE-SA and ISA as AY-SA, other European languages had would naturally pronounce it exactly opposite (EISA as AY-SA and ISA as EE-SA).

Meanwhile, on the firmware security front, some focused industry organizations are doing a great job of bring the reality of these issues to professionals and college students. For example, CS2AI (with more than 15 chapters worldwide) zeroes in on control systems and how they present unique challenges for security, as well as the recent impacts of the Meltdown and Spectre with excellent Q&A afterwards.

The UEFI plugfest in Seattle this past week brought a host of security related presentations. I presented on "UEFI and the Security Development Lifecycle". Many of the same process disciplines are becoming a requirement in the BIOS world because of the attention BIOS security is now getting from hackers, academics and professionals. This is also raising interesting business issues for a low-margin industry that has traditionally assumed its obscurity made it a low-priority target.

Intel's CHIPSEC team had a great presentation on how their threat models have now expanded to include attackers who have physical access to the hardware. There was a lot of other good stuff, which I'll talk about when the presentations become publicly available.