Unified Extensible Firmware Interface
The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is meant to replace the Basic Input/Output System (BIOS) firmware interface, present in all IBM PC-compatible personal computers. In practice, most UEFI images provide legacy support for BIOS services. UEFI can support remote diagnostics and repair of computers, even without another operating system.
The original EFI (Extensible Firmware Interface) specification was developed by Intel. Some of its practices and data formats mirror ones from Windows. In 2005, UEFI deprecated EFI 1.10 (final release of EFI). The UEFI specification is managed by the Unified EFI Forum.
The original motivation for EFI came during early development of the first Intel–HP Itanium systems in the mid-1990s. BIOS limitations (such as 16-bit processor mode, 1 MB addressable space and PC AT hardware) were unacceptable for the larger server platforms Itanium was targeting. The effort to address these concerns was initially called Intel Boot Initiative, which began in 1998 and was later renamed EFI.
In July 2005 Intel ceased development of the EFI spec at version 1.10, and contributed it to the Unified EFI Forum, which has evolved the specification as the Unified Extensible Firmware Interface (UEFI). The original EFI spec remains owned by Intel, which exclusively provides licenses for EFI-based products, but the UEFI specification is owned by the Forum.
Version 2.1 of the UEFI (Unified Extensible Firmware Interface) specification was released on 7 January 2007. It added cryptography, network authentication and the User Interface Architecture (Human Interface Infrastructure in UEFI). The current UEFI specification, version 2.3.1, was approved in April 2011.
The interface defined by the EFI specification includes data tables that contain platform information, and boot and runtime services that are available to the OS loader and OS. UEFI firmware provides several technical advantages over a traditional BIOS system:
- Ability to boot from large disks (over 2 TiB) with a GUID Partition Table, GPT.
- CPU-independent architecture
- CPU-independent drivers
- Flexible pre-OS environment, including network capability
- Modular design
Processor compatibility 
A normal PC BIOS is limited to a 16-bit processor mode and 1 MB of addressable space due to the design being based on the IBM 5150, which used the 16-bit Intel 8088. In comparison, the UEFI processor mode can be either 32-bit (x86-32, ARM) or 64-bit (x86-64 and Itanium). 64-bit UEFI understands long mode, which allows applications in the pre-boot execution environment to have direct access to all of the memory using 64-bit addressing.
UEFI requires the firmware and operating system loader to be size-matched; i.e. a 64-bit UEFI implementation can only load a 64-bit UEFI OS boot loader. After the system transitions from "Boot Services" to "Runtime Services," the operating system kernel takes over. At this point, the kernel can change processor modes if it desires, but this bars usage of runtime services (unless the kernel switches back again). Presently, the only operating system that supports running a kernel that is not size-matched to the firmware is Mac OS X.
Disk device compatibility 
In addition to the standard PC disk partition scheme, which uses a master boot record (MBR), EFI works with a new partitioning scheme: GUID Partition Table (GPT). GPT is free from many of the limitations of MBR. In particular, the MBR limits on the number and size of disk partitions (up to 4 primary partitions per disk, up to 2 TiB (240 bytes) per disk) are relaxed. GPT allows for a maximum disk and partition size of 8 ZiB (270 bytes). The UEFI specification explicitly requires support for FAT32 for system partitions, and FAT12/FAT16 for removable media; specific implementations may support other file systems.
Microsoft Windows 
EFI defines two types of services: boot services and runtime services. Boot services are only available while the firmware owns the platform (before the "ExitBootServices" call). Boot services include text and graphical consoles on various devices, and bus, block and file services. Runtime services are still accessible while the operating system is running; they include services such as date, time and NVRAM access. In addition, the Graphics Output Protocol provides limited runtime services support. The operating system is permitted to directly write to the framebuffer provided by GOP during runtime mode. However, the ability to change video modes is lost after transitioning to runtime services mode until the OS graphics driver is loaded.
Variable services 
UEFI variables provide a way to store data, in particular non-volatile data, that is shared between platform firmware and operating systems or UEFI applications. Variable namespaces are identified by GUIDs, and variables are key/value pairs. For example, variables can be used to keep crash messages in NVRAM after a crash for the operating system to retrieve after a reboot.
Time services 
UEFI provides device-independent time services. Time services include support for timezone and daylight saving fields, which allow the hardware real-time clock to be set to local time or UTC. On machines using a PC-AT real-time clock, the clock still has to be set to local time for compatibility with BIOS-based Windows.
EFI defines protocols as set of software interfaces used for communication between two binary modules. All EFI drivers must provide services to others via protocols.
Device drivers 
In addition to standard architecture-specific device drivers, the EFI specification provides for a processor-independent device driver environment, called EFI Byte Code or EBC. System firmware is required by the UEFI specification to carry an interpreter for any EBC images that reside in or are loaded into the environment. In that sense, EBC is similar to Open Firmware, the hardware-independent firmware used in PowerPC-based Apple Macintosh and Sun Microsystems SPARC computers, among others.
Some architecture-specific (non-EBC) EFI device driver types can have interfaces for use from the operating system. This allows the OS to rely on EFI for basic graphics and network functions until OS specific drivers are loaded.
Graphics features 
The EFI specification defined a UGA (Universal Graphic Adapter) protocol as a way to support device-independent graphics. UEFI did not include UGA and replaced it with GOP (Graphics Output Protocol), with the explicit goal of removing VGA hardware dependencies. The two are similar.
UEFI 2.1 defined a "Human Interface Infrastructure" (HII) to manage user input, localized strings, fonts, and forms (in the HTML sense). These enable OEMs or IBVs to design graphical interfaces for pre-boot configuration. UEFI itself does not define a user interface.
Most early UEFI implementations were console-based, but as early as 2007 some implementations featured a graphical user interface.
The UEFI specification defines a "boot manager", a firmware policy engine that is in charge of loading the OS loader and all necessary drivers. The boot configuration is controlled by a set of global NVRAM variables, including boot variables that indicate the paths to the loaders.
OS loaders are a class of UEFI applications. As such, they are stored as files on a file system that can be accessed by the firmware. Supported file systems include FAT32, FAT16 and FAT12. Supported partition table schemes include MBR and GPT. UEFI does not rely on a boot sector.
Boot loaders can also be auto-detected by firmware, to enable booting on removable devices. Auto-detection relies on a standardized file path to the OS loader, depending on the actual architecture to boot (\EFI\BOOT\BOOT[architecture name].EFI, e.g. \EFI\BOOT\BOOTx64.EFI).
It is common for UEFI firmware to include a user interface to the boot manager, to allow the user to select and load the operating system among the possible options.
Secure boot 
The UEFI 2.2 specification adds a protocol known as Secure boot, which can secure the boot process by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature. When secure boot is enabled, it is initially placed in "setup" mode, which allows a public key known as the "Platform key" (PK) to be written to the firmware. Once the key is written, secure boot enters "User" mode, where only drivers and loaders signed with the platform key can be loaded by the firmware. Additional "Key Exchange Keys" (KEK) can be added to a database stored in memory to allow other certificates to be used, but they must still have a connection to the private portion of the Platform key. Secure boot can also be placed in "Custom" mode, where additional public keys can be added to the system that do not match the private key.
Compatibility Support Module 
The Compatibility Support Module (CSM) is a component of the firmware that emulates a BIOS environment; allowing legacy operating systems and some option ROMs that do not support UEFI to still be used.
The EFI shell 
EFI provides a shell environment, which can be used to execute other EFI applications.
Extensions to EFI can be loaded from virtually any non-volatile storage device attached to the computer. For example, an original equipment manufacturer (OEM) can distribute systems with an EFI partition on the hard drive, which would add additional functions to the standard EFI firmware stored on the motherboard's ROM.
Implementation and adoption 
Intel EFI 
Intel's implementation of EFI is the Intel Platform Innovation Framework, codenamed "Tiano." Tiano runs on Intel's XScale, Itanium and IA-32 processors, and is proprietary software, although a portion of the code has been released under the BSD license or Eclipse Public License (EPL) as TianoCore. TianoCore can be used as a payload for coreboot.
Phoenix Technologies' implementations of UEFI include its SecureCore and SecureCore Tiano products. American Megatrends offers its own UEFI implementation known as Aptio, while Insyde Software offers InsydeH2O, its own implementation of Tiano.
Platforms using EFI/UEFI 
In January 2006, Apple Inc. shipped its first Intel-based Macintosh computers. These systems used EFI instead of Open Firmware, which had been used on its previous PowerPC-based systems. On 5 April 2006, Apple first released Boot Camp, which produces a Windows drivers disk and a non-destructive partitioning tool to allow the installation of Windows XP or Vista without requiring a reinstallation of Mac OS X. A firmware update was also released that added BIOS compatibility to its EFI implementation. Subsequent Macintosh models shipped with the newer firmware.
During 2005, more than one million Intel systems shipped with Intel's implementation of UEFI. New mobile, desktop and server products, using Intel's implementation of UEFI, started shipping in 2006. For instance, boards that use the Intel 945 chipset series use Intel's UEFI implementation.
The EDK (EFI Developer Kit) includes an NT32 target, which allows EFI firmware and EFI applications to run within a Windows application. But no direct hardware access is allowed by EDK NT32. This means only a subset of EFI application and drivers can be executed at the EDK NT32 target.
In 2008, more x86-64 systems adopted UEFI. While many of these systems still allow booting only the BIOS-based OSes via the Compatibility Support Module (CSM) (thus not appearing to the user to be UEFI-based), other systems started to allow booting UEFI-based OSes. For example, IBM x3450 server, MSI motherboards with ClickBIOS, all HP EliteBook Notebook and Tablet PCs, newer HP Compaq Notebook PCs (e.g., 6730b, 6735b, etc.).
In 2009, IBM shipped System x machines (x3550 M2, x3650 M2, iDataPlex dx360 M2) and BladeCenter HS22 with UEFI capability. Dell shipped PowerEdge T610, R610, R710, M610 and M710 servers with UEFI capability. More commercially available systems are mentioned in a UEFI whitepaper. Many Sandy Bridge PC platforms use UEFI.
In 2011 ASRock, ASUSTeK, Gigabyte Technology, and MSI launched several consumer-based motherboards using the Intel 6-series LGA 1155 chipset and AMD 9 Series chipset for AM3+ AMD FX (Bulldozer) and AMD Fusion processors with EFI.
With the release of Windows 8 in October 2012, Microsoft's certification requirements now require that computers include firmware that implements the UEFI specification. Furthermore, if the computer supports the "Connected Standby" feature of Windows 8, then the firmware is not permitted to contain a Compatibility Support Module (CSM). As such, systems that support Connected Standby are incapable of booting Legacy BIOS operating systems.
Operating systems 
An operating system that can be booted from a (U)EFI is called a (U)EFI-aware OS, defined by (U)EFI specification. Here the term booted from a (U)EFI means directly booting the system using a (U)EFI OS loader stored on any storage device. The default location for the OS loader is \EFI\BOOT\boot[architecture name].efi, where the architecture name can be e.g. IA32, X64 or IA64. Some OS vendors may have their own OS loader. They may also change the default boot location.
- The Linux kernel has been able to use EFI at boot time since early 2000, using the elilo EFI boot loader or, more recently, EFI versions of GRUB. Grub+Linux also supports booting from a GUID partition table without UEFI. The distribution Ubuntu added support for UEFI secure boot as of version 12.10. Further, the Linux kernel can be compiled with the option to run as an EFI bootloader on its own through the EFI bootstub feature.
- HP-UX has used (U)EFI as its boot mechanism on IA-64 systems since 2002.
- HP OpenVMS has used (U)EFI on IA-64 since its initial evaluation release in December 2003, and for production releases since January 2005.
- Apple uses EFI for its line of Intel-based Macs. Mac OS X v10.4 Tiger and Mac OS X v10.5 Leopard implement EFI v1.10 in 32-bit mode even on newer 64-bit CPUs, but full support arrived with Mac OS X v10.8 Mountain Lion.
- The Itanium versions of Windows 2000 (Advanced Server Limited Edition and Datacenter Server Limited Edition) implemented EFI 1.10 in 2002. MS Windows Server 2003 for IA-64, MS Windows XP 64-bit Edition and Windows 2000 Advanced Server Limited Edition, all of which are for the Intel Itanium family of processors, implement EFI, a requirement of the platform through the DIG64 specification.
- Microsoft introduced UEFI for x86-64 Windows operating systems with Windows Server 2008 and Windows Vista Service Pack 1 so the 64-bit versions of Windows 7 are compatible with EFI. 32-bit UEFI was originally not supported since vendors did not have any interest in producing native 32-bit UEFI firmware because of the mainstream status of 64-bit computing. Windows 8 includes further optimizations for UEFI systems, including a faster startup, 32-bit support, and secure boot support.
- On March 5, 2013, the FreeBSD Foundation awarded a grant to a developer seeking to add UEFI support to the FreeBSD kernel and bootloader.
Use of UEFI with virtualization 
- HP Integrity Virtual Machines provides UEFI boot on HP Integrity Servers. It also provides a virtualized UEFI environment for the guest UEFI-aware OSes.
- Intel hosts an Open Virtual Machine Firmware project on SourceForge.
- VMware Fusion 3 software for Mac OS X can boot Mac OS X Server virtual machines using EFI.
- VirtualBox has implemented UEFI since 3.1, but limited to Unix/Linux operating systems (doesn't work with Windows Vista x64 and Windows 7 x64).
- QEMU can be used with the Open Virtual Machine Firmware (OVMF) provided by TianoCore.
- The VMware ESXi version 5 hypervisor, part of VMware vSphere, supports virtualized EFI as an alternative to BIOS inside a virtual machine.
Numerous digital rights activitists have protested against UEFI. Ronald G. Minnich, a co-author of coreboot, and Cory Doctorow, a digital rights activist, have criticized EFI as an attempt to remove the ability of the user to truly control the computer. It does not solve any of the BIOS's long-standing problems of requiring two different drivers—one for the firmware and one for the operating system—for most hardware.
The open-source project, TianoCore, provides the UEFI interfaces. TianoCore lacks the specialized drivers that initialize chipset functions, which are instead provided by Coreboot, of which TianoCore is one of many payload options. The development of Coreboot requires cooperation from chipset manufacturers to provide the specifications needed to develop initialization drivers.
Secure boot 
In 2011, Microsoft was accused by critics and free software/open source advocates (including the Free Software Foundation) of trying to use the secure boot functionality of UEFI to hinder or outright prevent the installation of alternative operating systems such as Linux, by requiring that new computers certified to run its Windows 8 operating system ship with secure boot enabled using a Microsoft private key. Following the criticism, Microsoft denied that the secure boot requirement was intended to serve as a form of lock-in, and clarified its requirements by stating that systems certified for Windows 8 must allow secure boot to enter custom mode or be disabled, but not on systems using the ARM architecture.
Other developers raised concerns about the legal and practical issues of implementing support for secure boot on Linux systems in general. Former Red Hat developer Matthew Garrett noted that conditions in the GNU General Public License version 3 may prevent the use of the GRUB bootloader without a distribution's developer disclosing the private key (however, the Free Software Foundation has since clarified its position, assuring that the responsibility to make keys available was held by the hardware manufacturer), and that it would also be difficult for advanced users to build custom kernels that could function with secure boot enabled without self-signing them. Other developers suggested that signed builds of Linux with another key could be provided, but noted that it would be difficult to persuade OEMs to ship their computers with the required key alongside the Microsoft key.
Several major Linux distributions have developed different implementations for secure boot. Matthew Garrett himself developed a minimal bootloader known as shim; a pre-compiled, signed bootloader that allows the user to individually trust keys provided by distributors. Ubuntu 12.10 uses an older version of shim pre-configured for use with Canonical's own key that only verifies the bootloader and allows unsigned kernels to be loaded: developers believed this practice of only signing the bootloader is more feasible, since a trusted kernel is only effective at securing user space and not the pre-boot state (which secure boot is designed to protect). This also allows users to build their own kernels and use custom kernel modules as well, without needing to re-configure the system. Canonical also maintains its own private key to sign installations of Ubuntu pre-loaded on certified OEM computers that run the operating system, and also plans to enforce a secure boot requirement as well—requiring both a Canonical key and a Microsoft key (for compatibility reasons) to be included in their firmware. Fedora also uses shim, but requires that both the kernel and its modules be signed as well.
It has been disputed whether the kernel and its modules must be signed as well; while the UEFI specifications do not require it, Microsoft has asserted that their contractual requirements do, and that it reserves the right to revoke any certificates used to sign code that can be used to compromise the security of the system. In February 2013, another Red Hat developer attempted to submit a patch to the Linux kernel that would allow it to parse Microsoft's authenticode signing using a master X.509 key embedded in PE files signed by Microsoft. However, Linus Torvalds, the creator of Linux, attacked the proposal for supporting Red Hat's desire to “deep-throat” Microsoft and participate in their “dick-sucking” for supporting their regime.
On March 26 2013, the Spanish free software development group Hispalinux filed a formal complaint with the European Commission, contending that Microsoft's secure boot requirements on OEM systems were "obstructive" and anti-competitive.
Firmware issues 
The increased prominence of UEFI firmware in devices have also led to a number of technical issues blamed on their respective implementations.
Following the release of Windows 8 in late-2012, it was discovered that certain Lenovo computer models with secure boot had firmware that was hard-coded to only allow executables named "Windows Boot Manager" or "Red Hat Enterprise Linux" to load, regardless of any other setting. Other issues were encountered by several Toshiba laptop models with secure boot that were missing certain certificates required for its proper operation.
In January 2013, a bug surrounding the UEFI implementation on some Samsung laptops was publicized, which caused them to be bricked after installing a Linux distribution in UEFI mode. While potential conflicts with a kernel module designed to access system features on Samsung laptops were initially blamed (also prompting kernel maintainers to disable the module on UEFI systems as a safety measure), Matthew Garret uncovered that the bug was actually triggered by storing too many UEFI variables to memory, and that the bug could also be triggered under Windows as well under special conditions. In conclusion, he determined that the offending kernel module had caused kernel message dumps to be written to the firmware, thus triggering the bug.
See also 
- Advanced Configuration and Power Interface (ACPI)
- Functional specification
- Open Firmware
- Platform Initialization Specification
- System Management BIOS (SMBIOS)
- System Management Mode (SMM)
- Trusted Platform Module (TPM)
- Unified EFI Forum
- Michael Kinney (1 September 2000). "Solving BIOS Boot Issues with EFI" (PDF). pp. 47–50. Retrieved 14 September 2010.
- . The Register. 23 September 2011 http://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/. Retrieved 24 September 2011. Text "MS denies secure boot will exclude Linux" ignored (help); Missing or empty
- "The 30-year-long Reign of BIOS is Over: Why UEFI W... - Input Output". H30565.www3.hp.com. Retrieved 2012-03-06.
- Matthew Garrett (Jan 19, 2012). "EFI and Linux: the future is here, and it's awful - Matthew Garrett". linux.conf.au 2012. Retrieved 2 April 2012.
- "Emulex UEFI Implementation Delivers Industry-leading Features for IBM Systems" (PDF). Emulex. Retrieved 14 September 2010.
- Extensible Firmware Interface (EFI) and Unified EFI (UEFI), Intel, archived from the original on 2010-01-05
- Wei, Dong (2006), "foreword", Beyond BIOS, Intel Press, ISBN 978-0-9743649-0-2
- "1.10 Specification overview", Extensible Firmware Interface, Intel
- About, Unified EFI Forum, "Q: What is the relationship between EFI and UEFI? A: The UEFI specification is based on the EFI 1.10 specification published by Intel with corrections and changes managed by the Unified EFI Forum. Intel still holds the copyright on the EFI 1.10 specification, but has contributed it to the Forum so that the Forum can evolve it. There will be no future versions of the EFI specification, but customers who license it can still use it under the terms of their license from Intel. The license to the Unified EFI Specification comes from the Forum, not from Intel"
- "UEFI and Windows". Microsoft. 15 September 2009. Retrieved 14 September 2010.
- Large disk support and features such as Advanced Configuration and Power Interface (ACPI) and System Management BIOS (SMBIOS) were subsequently implemented in BIOS-based systems.
- https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html -- grub 2 needs a special ~2MB partition on GUID distributions to place itself to work. You can create this with gparted.
- UEFI specification 2.3.1, section 1.8.1.
- Hardwidge, Ben (1 June 2010). "LBA explained — Solving the 3TB Problem?". bit-tech. Retrieved 18 June 2010.
- Brian Richardson (10 May 2010). "Ask a BIOS Guy: "Why UEFI"". Intel Architecture Blog. Retrieved 18 June 2010.
- Gary Simpson. "UEFI Momentum — The AMD perspective" (PPTX). AMD. Retrieved 18 June 2010.
- UEFI Specification, sections 2.3.2 and 2.3.4
- "FAQ: Drive Partition Limits" (PDF). UEFI Forum. Retrieved 9 June 2010.
- Bill Boswell (1 July 2002). "FAQ: Drive Partition Limits". Redmond Mag. Retrieved 9 June 2010. "GPT disks also support very large partitions thanks to a 64-bit Logical Block Address scheme. A logical block corresponds to one sector, or 512 bytes, yielding a maximum theoretical capacity of eight zettabytes."
- https://wiki.archlinux.org/index.php/GUID_Partition_Table#Kernel_Support. Missing or empty
- For Microsoft Windows Vista (x64), it is possible only if installed from an installation DVD of Microsoft Windows Vista (x64) with its service pack 1 or 2 integrated.
- "Samsung UEFI bug: Notebook bricked from Windows". The H. Retrieved 27 February 2013.
- UEFI specification, section 7.3
- Intel shows PC booting Windows with UEFI firmware
- Edge, Jake. "UEFI and "secure boot"". Linux Weekly News. Retrieved 9 September 2012.
- "Windows 8 Secure Boot: The Controversy Continues". PC World. Retrieved 9 September 2012.
- "TianoCore - coreboot". Retrieved 25 May 2012.
- "SecureCore Tiano™". Phoenix Technologies. Retrieved 14 September 2010.
- "Aptio®: The Complete UEFI Product Solution" (PDF). American Megatrends, Inc. Retrieved 8 January 2011.
- "InsydeH2O UEFI Framework". Insyde Software Corp. Retrieved 8 January 2011.
- Apple Computer. "Universal Binary Programming Guidelines, Second Edition: Extensible Firmware Interface (EFI)"
- Apple's Transition from Open Firmware to Extensible Firmware Interface, mactech, 2007.
- "Intel® Platform Innovation Framework for UEFI Overview". Intel. Retrieved 14 September 2010.
- Evaluating UEFI using Commercially Available Platforms and Solutions (PDF), UEFI, 2011‐5
- Asus P67 Motherboard Preview, .
- Windows Hardware Certification Requirements for Client and Server Systems, Microsoft, 2013-1
- Announcement of release 3.5pre1 by maintainer Brett Johnson made on 2004-02-27.
- EFI version of Grub, Debian GNU/Linux, retrieved 1 May 2008
- "Ubuntu will use GRUB 2 for its Secure Boot implementation". The H Online. Retrieved 28 October 2012.
- OpenVMS Release History, HP, retrieved 16 September 2008
- rEFIt — Windows Vista and EFI, SourceForge
- "Extensible Firmware Interface", Windows Server TechCenter, Microsoft
- "Unified Extended Firmware Interface support in Windows Vista". Microsoft. 26 October 2006. Retrieved 12 June 2010. "Microsoft determined that vendors would not have any interest in producing native UEFI 32-bit firmware because of the current status of mainstream 64-bit computing and platform costs. Therefore, Microsoft originally did not to ship support for 32-bit UEFI implementations."
- "Microsoft Touts Incredible Windows 8 Boot Times". Retrieved September 9, 2011.
- Jon Brodkin (21 September 2011). "Windows 8 secure boot could complicate Linux installs". Ars Technica. Retrieved 23 September 2011.
- "FreeBSD to get UEFI support". The H. Retrieved 7 March 2013.
- Open Virtual Machine Firmware, SourceForge
- 3.1 Changelog, VirtualBox
- Ticket 7702, VirtualBox
- "Statement by sr. software engineer at Oracle", Forum, VirtualBox
- "Interview: Ronald G Minnich". Fosdem. 6 February 2007. Retrieved 14 September 2010.
- http://boingboing.net/2011/12/27/the-coming-war-on-general-purp.html Missing or empty
- "coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware". YouTube. 31 October 2008. Retrieved 14 September 2010.
- "Welcome", TianoCore, SourceForge
- "Is Microsoft Blocking Linux Booting on ARM Hardware?". Compurer World UK. Retrieved 2012-03-06.
- "Shimming your way to Linux on Windows 8 PCs". ZDNet. Retrieved 26 February 2013.
- "Ubuntu details its UEFI secure boot plans". Linux Weekly News. Retrieved 11 September 2012.
- "No Microsoft certificate support in Linux kernel says Torvalds". The H. Retrieved 26 February 2013.
- "Linus Torvalds: I will not change Linux to “deep-throat Microsoft”". Ars Technica. Retrieved 26 February 2013.
- "Exclusive: Open software group files complaint against Microsoft to EU". Reuters. Retrieved 26 March 2013.
- "Linux on Windows 8 PCs: Some progress, but still a nuisance". ZDNet. Retrieved 26 February 2013.
- "Lenovo UEFI Only Wants To Boot Windows, RHEL". Phoronix. Retrieved 26 February 2013.
- "Linux acquitted in Samsung laptop UEFI deaths". Bit-tech. Retrieved 26 February 2013.
- "Booting Linux using UEFI can brick Samsung laptops". The H. Retrieved 26 February 2013.
Further reading 
- Zimmer, Vincent; Rothman, Michael; Hale, Robert (10 May 2007). "EFI Architecture". Dr. Dobb's Journal. UBM. Retrieved 12 October 2012.
- De Boyne Pollard, Jonathan (11 July 2011). "The EFI boot process". Frequently Given Answers. Retrieved 12 October 2012.
- De Boyne Pollard, Jonathan (8 December 2011). "The Windows NT 6 boot process". Frequently Given Answers. Retrieved 12 October 2012.
- Smith, Roderick W. (2011). "A BIOS to UEFI Transformation". Roderick W. Smith's Web Page. Retrieved 12 October 2012.
- Kothari, Rajiv (21 September 2011). "UEFI – Just How Important It Really Is". Hardware Secrets. Retrieved 12 October 2012.
- Fisher, Doug (2011). "UEFI Today: Bootstrapping the Continuum". Intel Technology Journal (Intel) 15 (01). ISBN 9781934053430. Retrieved 12 October 2012.
|Wikimedia Commons has media related to: Extensible Firmware Interface|