Three Pivotal Features Differentiate Bootloading Options

Electronicdesign Com Sites Electronicdesign com Files Uploads 2015 01 Author

Scott Hoot, President and CEO, Sage Electronic Engineering

For decades, even computer experts favoring alternative operating systems for x86 processors showed little concern with how their systems reached the OS—initialization stages typically called boot, bootloading, or bootstrapping options. That began to change shortly before the turn of the century as data-center administrators started dealing with larger clusters of servers, which caused them to rethink the speed and security of their booting methods. Also, the physical footprint of boot firmware—the term was taken from the phrase “pull yourself up by your own bootstraps”—became more important as the cost of embedded flash with large server clusters gained significance.While boot methodologies can vary extensively with different x86 processors and operating systems, network administrators are becoming increasingly aware of how their systems boot from microprocessing hardware to operating systems. The size of embedded flash needed to run these systems, as well as boot speeds and security, are all concerns. Addressing these elements for a few key technologies, namely BIOS, UEFI, and open-source bootloaders, is an important first step in evaluating boot options.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

Legacy BIOS

Legacy BIOS (basic input/output systems) held sway for 30 years before OEMs and consumers began to question the efficacy and cost of these systems. Essentially, the major BIOS vendors, such as American Megatrends (AMI), Byosoft, Insyde Software, and Phoenix Technologies, had Trusted Partner status with the big x86 chip manufacturers and were allowed to work closely with the highly protected proprietary chip architecture. As such, Legacy BIOS solutions began to appear expensive, both in initial costs and the accrued cost of paying a royalty on each PC or server blade that was sold.

The term BIOS is somewhat misleading, because a complete BIOS does substantially more in terms of testing and initializing the system’s hardware components and then loading the operating system from a mass memory device (Fig. 1). Besides running code embedded on flash devices, BIOS also loads the Master Boot Record (MBR) from the first section of the mass memory, or hard disk.

Electronicdesign Com Sites Electronicdesign com Files Uploads 2015 01 Sage Ee Fig1 Small

1. Legacy, or proprietary, BIOS boots are often unprotected during initialization phases, which leaves the system open to rootkit malware.

For backward compatibility—a key element of the x86 ecosystem—the BIOS could only run in 16-bit mode and it usually contained only four primary partition table entries, which were also limited in size in the MBR partition table scheme. These factors ultimately slowed the boot speed and increased the amount of necessary code.

BIOS packages were written specifically for OEM products, such PCs and servers, as well as embedded systems. However, they also had to be versatile enough for consumers to adopt new software and hardware additions, plus be backward-compatible with previous systems, leading to a great deal of code bloat. Subsequent additions to the BIOS could not be easily handled by software development at the OEMs, which had to turn to the BIOS vendor for subsequent support.

UEFI

Intel began developing the Extensible Firmware Interface (EFI) in the mid-1990s as a replacement for BIOS on server systems. The 16-bit processing mode and other BIOS speed limitations, as well as configuration requirements, were concerns for larger server platforms under development at that time.

By the time Intel handed off EFI to a consortium of OEMs dedicated to a Unified Extensible Firmware Interface (UEFI) in 2005, security had become a major concern with BIOS-based systems. Although the BIOS providers attempted to cover their code by releasing only binary images of the machine code, malicious hackers were able to take over many systems through rootkits and hide their malware from the booting systems.

While Hewlett-Packard was an early implementer of EFI in 2002, other OEMs were slower to adopt the firmware solution. With its first Intel-based Macintosh computers released in 2006, Apple began shipping EFI and subsequently adopted the unified version.

In 2008, adoption of the UEFI firmware became more widespread though IBM x86 servers and HP notebooks and tablet PCs. Microsoft adopted UEFI for a later version of Windows 7, and by 2012, it was a certification requirement on all Windows 8 computers.

Like BIOS, UEFI is a proprietary package that also can be easily deployed by software engineers without having to address much of what has typically been known as firmware or embedded development. The UEFI code is complete, works on multiple platforms essentially out of the box, and can run in 32- and 64-bit modes (Fig. 2). Several other benefits of UEFI over BIOS include its built-in boot manager, which eliminates the need for separate boot loaders.

Electronicdesign Com Sites Electronicdesign com Files Uploads 2015 01 Sage Ee Fig2 Small

2. Proprietary UEFI boots are protected through the initialization phase, but have a large hardware footprint unless extensively optimized.

The “Secure Boot” feature is both a major attraction and major detraction of the UEFI platform. Microsoft implemented the feature to help overcome insecurities that would affect its Windows system. However, the Microsoft-centric implementation has also led to difficulty with the Linux community because Secure Boot makes it very difficult to install alternative operating systems. Secure Boot checks the digital signatures of loading programs, allowing only authenticated drivers and services to load.

An increasing number of security experts have warned that running UEFI without Secure Boot is a substantial risk. Much of the code base, which extremely large due to the system’s universality, is open without having the support of an open-source community, such as that enjoyed by Linux or coreboot. In addition, reports have surfaced of malicious rootkits installed on UEFI with Secure Boot in operation.

The size of the embedded flash needed to run UEFI, as well as its boot speed, have created headaches for many network administrators. Embedded flash requirements of more than 12 MB are not uncommon, which becomes an issue spread across thousands of server nodes in a cloud environment. Part of the problem is the universality of the UEFI system working on many x86 chipsets and for many diverse operating system platforms. Modification of the UEFI package is essentially done through elimination—eliminating unnecessary code for a particular board configuration and operating system. However, there are a few examples of network administrators significantly shrinking the required size.

Other issues include the fact that UEFI is not commonly thought of when it comes to reducing boot times. It’s a concern that will become increasingly important in a software-defined network environment, though. In addition, UEFI is very much like an underlying operating system; it will remain in some powered state once the actual OS begins initiation, increasing network power usage and cooling costs.

Open-Source Bootloaders

Although, technically, Legacy BIOS and UEFI could be considered bootloaders, the term is more frequently applied to smaller, open-source booting options that have dominated the ARM ecosystem, such as U-Boot, Open Firmware (aka: OpenBoot), or RedBoot. Open-source solutions are more common with ARM processors, primarily because the chip architecture itself is open. In fact, some ARM systems-on-a-chip (SoCs) actually assist the hardware initialization (first-stage boot loading) with their own data.

In the x86 environment, bootloader choices are more limited, largely due to the proprietary nature of the chip architecture. U-Boot has been used as a first-stage bootloader on a very limited number of x86 processors, but isn’t widely viewed as a valid alternative for newer chip releases.

Electronicdesign Com Sites Electronicdesign com Files Uploads 2015 01 Sage Ee Fig3

3. An open-source coreboot initialization can be protected from rootkit intrusion.

Manufacturers looking for a first-stage bootloader that initializes the hardware almost always turn to coreboot (Fig. 3). It’s supported by AMD Agesa open-space code, as well as the Agesa (closed-source) binary solution and Intel’s Firmware Support Package (FSP) binary. The binaries create an abstraction layer from which firmware developers can access the microprocessors. While open-source proponents would prefer access without the binaries, the FSP and Agesa systems have moved embedded development closer in time to the chip release, meaning embedded development can occur on more recent chip releases.

Open-source coreboot can be used as either a first-stage bootloader, or a first- and second-stage bootloader. As a first-stage bootloader, it usually hands off the second-stage chores to either a GRUB variant to load Linux OS platforms, or SeaBIOS to load either Windows or Linux. A number of other second-stage bootloaders are also available. As a first- and a second-stage bootloader, coreboot can also load Linux and Sage XOS. In addition, the number of second-stage bootloaders is increasing, with alternatives such as Embedded Linux.

Furthermore, coreboot was developed (in the late 1990s) as an alternative to Legacy BIOS in server environments. Essentially, its author, Ron Minnich, found that it simply took too long to update his Linux cluster because of the time it took for each node to reboot.

A primary reason network administrators opt for coreboot in an x86 ecosystem is the reduced boot time. In fact, coreboot has been used to boot an Intel Atom E3800 SoC, in advance of loading the OS kernel, in 700 ms. Such boot speed is possible by streamlining the boot sequence, eliminating all unnecessary code when bringing up the system.

In addition to improving boot performance, code reduction is a key to security audits in firmware solutions. By reducing the overall lines of code, firmware developers also shrink the “attack surface”—the amount of code that could be subject to malware injection. Moreover, open-source software is subject to a review by members of the community, usually referred to as a “many eyes” solution to reducing vulnerable code. By streamlining solutions for specific boards, as in network administration, firmware developers can often reduce potential vulnerabilities in the firmware by one of two orders of magnitude, making it much easier to clean and test the final code.

Conclusion

Network administrators currently using Legacy BIOS should certainly consider UEFI or open-source bootloaders in their next upgrade, especially if there are significant vectors of malware attack. UEFI is widely deployed in the overall x86 network ecosystem, thanks in large part to support from Intel, Microsoft, and other network solution providers.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

Such support may be a key reason to consider UEFI for smaller networks. However, UEFI’s proprietary costs, as well as costs for embedded flash and cooling, should entice many administrators to take a look at open-source bootloaders in their next upgrade. Certainly, any administrator contemplating a software-defined network should give open-source bootloaders serious thought.

Scott Hoot is president and CEO of Sage Electronic Engineering, a full-service engineering design, product development, and training firm specializing in open-source firmware development for embedded, COTS, and custom hardware platforms. He can be reached at [email protected].