UEFI

UEFI News and Commentary

Saturday, April 21, 2018

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.





Thursday, April 05, 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).

Sunday, April 01, 2018

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.

Friday, August 04, 2017

So What Does Security In IoT With UEFI Really Look Like?

As usual, security continues to dominate the news about UEFI. DEFCON had several presentations related to firmware security. There is a good overview of the hardware and firmware attacks discussed over at Dark Reading. This included one by my friend Vincent Zimmer and his colleagues at Intel analyzing over 90 reported firmware vulnerabilities over the past 3 years. He discusses his experience on his blog. Another, by security researcher Alex Matrosov described exploits and called out specific computer models. Then there was some stuff on using CHIPSEC to detect improperly configured chipsets.

As often as I deal with security issues in firmware, I am still ignorant of how the types of exploits that are available and the tools that are used by cyber-security professionals. There are always new kits coming out, with new features. But where do you get them and how do you use them safely without making you and your computer system a target-rich environment? Recently the CS2AI of Sacramento hosted two lectures. The first lecture focused on giving the nuts and bolts (step-by-step) of setting up your own environment, including virtual machines, TOR and Kali and even configuring a cheap Raspberry Pi as an analysis tool. The second lecture focused on the tools available under Kali, such as password hash crackers (with an up-close hack that used it), Sparta and Wireshark for network analysis and then an introduction to using Tor to venture onto the dark net with Tor. Why the dark net? So that you can see how much it costs to buy a hack of your company or a company that you care about!

Next month will be wireless attacks and the tools that sniff out vulnerabilities. Good stuff.

Security today has a lifespan-in hours, or maybe in months or years. My firmware job is to keep your system secure for the duration of one boot.

Wednesday, June 07, 2017

UEFI Releases New Specifications and Adds ARM to the Board

For anyone who has been working on the UEFI specification, for the past few years, it should be no surprise to hear that UEFI has decided to welcome ARM onto the board of directors. This shows the growth of interest in firmware standards by the non-x86 world and also recognizes ARM's outstanding level of effort to improving the specifications. Dong Wei, who was the vice president of UEFI while at HP, now returns to the same role but now from ARM, where he is the senior director platform architecture. This seems like a smart move on both sides.

This announcement came on the heels of the release of a spate of new spec and test tool revisions. There are a whole bunch of goodies in here, from wifi and BlueTooth to new SMM (now called MM) models (including TrustZone!).


There are rumblings about another UEFI plugfest in the works. More on what's changes in the specs and other industry happenings later.

Thursday, June 01, 2017

UEFI Security In The News: Craigslist, Zimmer & Cyber-Security Meet Ups

Using a UEFI-based BIOS on a MacBook Pro/Air and forgot your password and live in New York, New Jersey or Connecticut? Craigslist to the rescue! From the ad:
REMOVAL PROCESS: the password removal process will NOT damage your Macbook or VOID your Apple warranty in any way we do not modify any hardware nor do we use any software to remove the password a professional external password analyser will be used to remove the EFI Firmware BIOS Password and/or the iCloud System Lock PIN Code the repair turnaround will take 1 HOUR
Not sure how this works and I don't have a Mac, but some people have done extensive reverse engineering to look at it and found it pretty solid. Barring access to a hardware flash programmer "...there is no way for an outsider to generate the codes to reset your Mac firmware. So please stop sending me emails and comments asking for it."

Meanwhile, everyone seems to be trying to hack the firmware, even to the point where firmware guys are starting to worry about how solid the firmware written by other guys really is. My friend and co-author Vincent Zimmer gives a pretty good round up of the current findings and presentations, including some of his own.

Meanwhile, the local chapter of CS2AI is sponsoring a series of security meetings that gathers local industry practitioners and educators together to discuss different topics surrounding IT and control-system security. Last time the focus was on "The Mind of a Cyber Attacker" The next topic will be Defensive Tools for Cyber-Security, hosted by Prof. Jun Dai at Sacramento State University. Recent sessions have been hosted by speakers from McAfee, Palo Alto Networks and Grimm. Good stuff, practical from the physical, hardware, software and network attacks.

Some OEMs are more paranoid than others. In the firmware world, that keeps us on our toes to engineer creative solutions that make systems buildable, shippable and usable but not vulnerable.

Sunday, May 21, 2017

Using C++ With EDK2, Part 1: new and delete

This is the first in a series of articles looking at what it takes to compile a UEFI C++ application under EDK2. This isn't an attempt to cover everything. I'm not a compiler library expert, so I'm not trying to port everything in the STL over. Nor am I a regular GCC user, so my efforts have been focused on Visual Studio 2015. Finally, I am focused on UEFI Shell applications, rather than normal UEFI apps or UEFI drivers.

I was initially intrigued by the fact that "#ifdef __cplusplus" occurs in several places. It appears in the StdLib header files, but that makes sense since they were originally a port from an environment that supported C++ and C. It also appears in the AutoGen.h files that are automatically created by the EDK2 build system for each module. It looks something like this:

#ifdef __cplusplus
extern "C" {
#endif

#include
#include
#include

extern GUID  gEfiCallerIdGuid;
extern CHAR8 *gEfiCallerBaseName;
...

// Guids
extern EFI_GUID gEfiAuthenticatedVariableGuid;
extern EFI_GUID gEfiVariableGuid;
...

// Definition of PCDs used in this module
#define _PCD_TOKEN_PcdFlashNvStorageVariableBase  5U
...
EFI_STATUS
EFIAPI
PeimInitializeVariableServices (
  IN       EFI_PEI_FILE_HANDLE  FileHandle,
  IN CONST EFI_PEI_SERVICES     **PeiServices
  );
...
#ifdef __cplusplus
}
#endif

That is, all of the C symbols that are automatically included into the build have the extern "C" linkage specifier placed around them so that they will handle calls from either C or C++ source code. So someone was thinking about C++.

For my solution, which is checked in on SourceForge here, I started simply by handling the necessary support for the new and delete operators, with no support for exceptions. This C++ library depends on the StdLib C library that comes with EDK2. For the most part, the C headers would work just fine, but two critical files (MdePkg/Include/Base.h and StdLib/Include/sys/EfiCDefs.h) generate errors when pulled in to C++ code. For now, I simply created new, slightly modified versions to work around the minor issues. This requres that your .inf file list the new library before listing the StdLib.

[Packages]
  SysLib/SysLib.dec
  StdLib/Stdlib.dec

This changes the include order so that, if there is a modified version for the C++ library, it will be preferred over the one in StdLib.

So far, only the new header file declares anything of substance. The others (wchar.h, stdlib.h, stdio.h) just provide wrappers for the StdLib that bring in the versions of Base.h and EfiCDefs.h that work with the library.

But the results are pretty nice. Assuming you don't need exception handling or the C++ standard library, you can use all of the normal C++ features, such as classes and inheritance and templates.

This is just the starting point. Over the next articles, I will expand the support for both the C++ and C libraries.