New Ways to Talk to Hardware

Twenty years from now, our desktops and servers will no
longer have the structure they have today. There will be new forms of hardware
and the definition of 'high-end' would have changed many times over. In such
a situation, the specifications drawn up in the last millennium can scarcely be
expected to fulfill the needs of the computing world. Instead, new ways to
interact with our hardware now and then must exist. Limitations of the current
environment are far too many; one of the biggest ones being recursively handed
down from the IBM PC era-that of a difference between the real and protected
mode. Already, OS have to run in protected mode from the start. And they grow
large and unwieldy with a number of drivers bundled in. Problems increase too,
as each vendor writes drivers for a plethora of platforms it must cater to, and
at the same time maintain levels of functionality and performance. A video card
for a PC cannot choose to work only in Windows today (and even in that, only for
a particular version). It needs to work equally well in Linux and UNIX, and any
number of platforms that the user might choose to deploy.

What's the cure?

The solution to this muddle is to close the box and take it back to
'square one', when OS did not carry drivers. Drivers are bundled within
hardware in a platform independent, OS independent, and software independent
manner. And they must be a transparent layer visible to the OS but not a part of
it. Visible to the BIOS of the system, and not a part of that either. It must be
small, not being so large itself that the rest of the system is starved for
memory. And it should do all that from a location where it can be managed and
kept up to date.

Immediate uses

The first immediate use such a technology can bring into effect is
virtualization at the lowest possible level. It would no longer be necessary to
have a middle layer for virtualization to abstract the components and sacrifice
on performance. The hardware driver layer itself could perform this process
transparently. This would be easy because the driver layer would lie between the
different OS running and the BIOS.

It is also theorized that since the drivers for the
hardware would be platform independent, hardware vendors do not need to develop
multiple versions of the same component for different types of systems (for
example, one set for 32 bit and another for 64 bit). The same physical component
would run identically without requiring any modifications to itself or to its
driver software on all platforms, under all OS environments.

This is also being promoted as the technology used to
realize the much-hyped 'Trusted Computing' dream. A pre-boot high-level
environment, that is free from the shackles of lower memory addressability and
limited instruction/function set, can be used to enforce a variety of pro-active
or passive security and protection mechanisms.

EFI based systems can also run specially written EFI
applications before the system is 'booted'. These applications can be for a
variety of purposes, such as enterprise-specific monitoring and management.

Introducing EFI

This is a technological innovation from Intel, called the Extensible
Firmware Interface or EFI for short. This is a specification that allows BIOS
vendors to develop their own implementation of a driver driven model BIOS. The
current version is 1.1 and is licensed from Intel. However, a part of the code
base of EFI has been released to the open source community under a project
called TianoCore (www.tianocore.org). Currently, the only desktop computers to
be shipping with EFI are the Intel-powered Macs. However, this doesn't mean
that the PC world will never see them, because the 64 bit editions of Win XP,
Server 2003, as well as the upcoming
Vista
releases are already EFI aware and fully support it. In fact,
Vista
is EFI-only, working with traditional ACPI and SMBIOS systems through something
called a CSM (Compatibility Support Module). The Linux world is on the EFI track
too. The RHEL, for instance, is already EFI ready. Servers such as those from
the 'Integrity' range from HP already feature the EFI BIOS. And to take
advantage of this, the HP-UX OS is also EFI aware. American Megatrends, the
vendor of 'AMIBIOS', has released their implementation of EFI 1.1 under the
name 'Aptio'.Aptio features support for abilities such as hidden system
partitions on hard disks, pre-boot environments, and an OS-less shell with a
variety of features (like disaster recovery, update over the Net and system
management). The system partition, for instance, can be used to store the
hardware drivers and the pre-boot environment software. And all of this is very
extensible, since developers can build their own features using a high-level C
language and hook into the EFI system using 32-bit API.

For BIOS-based systems, each hardware would require a driver at the OS level. This makes the software bulky and also necessitates separate drivers for each OS being run. With EFI, the drivers are integrated into the pre-OS environment removing such problems

EFI file system

The technology mandates the presence of at least one special partition on
the hard disk called the EFI partition. There are two kinds of EFI partitions
— one is the system partition, and other are regular partitions that contain
other EFI data. These partitions would contain a specific set of files. This FS
is based on the FAT format. The system partitions would use the FAT-32 system,
while any USB and removable media used will have the FAT-16 or FAT-12. The
partition contains bootable EFI images, config files and other directories.
These partitions would by definition have a '\EFI' and a TOOLS
sub-directory. The EFI engine would search within this tree for bootable images
after POST. EFI partitions cannot be mounted by the OS. This also prevents data
in the EFI from being corrupted.

Implications

As computers become more powerful with per-system resources being heavily
under-utilized in an average working day, technologies such as EFI would enable
off-the-shelf desktops to be better utilized. It would also reduce the burden of
providing several systems for competing platforms for the workers that need
them. Software developers can take advantage of this by having to produce only a
single version of products without worrying about platform and architectural
differences. The gap between x86, ia64, ppc and other architectures is now set
to close completely in the coming years.

Sujay V Sarma