Search My Blog

Sunday, June 24, 2012

Unified Extensible Firmware Interface (UEFI) - Windows 8 Secure Boot - Fedora, Ubuntu and Arch Linux Distros, Respond

I have Researched and collected some info on the Unified Extensible Firmware Interface (UEFI). Commonly known as, Windows 8 Secure Boot. And on how Fedora, Ubuntu and Arch Linux Distros, have Responded so far (as of 06-24-12). Here it is..

Don

Windows 8 Secure Boot: Two Linux Distros Respond

By Katherine Noyes, PCWorld

Controversy has been raging over Microsoft's Windows 8 Secure Boot plans ever since they were first revealed last fall, and there's still no sign that that will change anytime soon.

Now the leading Linux distributions are beginning to respond with an outline of how they plan to deal with the restrictions imposed by Microsoft's plans.

First it was Fedora, which revealed its strategy late last month. Then, this week Canonical spoke up in turn with its own plans for Ubuntu Linux.

The two distros are taking pretty different approaches. Here's an overview of what they've each said.

What We Know So Far

For those who missed it, a quick recap on what's coming our way: Basically, future Windows 8 hardware will come with the Secure Boot technology enabled in the Unified Extensible Firmware Interface (UEFI), meaning that only operating systems with an appropriate digital signature will be able to boot.

Read More...
http://www.pcworld.com/businesscenter/article/258153/windows_8_secure_boot_two_linux_distros_respond.html

Unified Extensible Firmware Interface

From Wikipedia, the free encyclopedia
Jump to: navigation, search
UEFI Logo
Extensible Firmware Interface's position in the software stack.

The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is meant as a replacement for the BIOS firmware interface, present in all IBM PC-compatible personal computers.[1][2] In practice, most UEFI images have legacy support for BIOS services. It can be used to allow remote diagnostics and repair of computers (and security exploits), even without another operating system. [3]

The original EFI (Extensible Firmware Interface) specification was developed by Intel. Some of its practices and data formats mirror ones from Windows.[4][5] In 2005, UEFI deprecated EFI 1.10 (final release of EFI). The UEFI specification is managed by the Unified EFI Forum.

Contents

History

The original motivation for EFI came during early development of the first Intel–HP Itanium systems in the mid-1990s. PC BIOS limitations (16-bit processor mode, 1 MB addressable space, PC AT hardware dependencies, etc.) were seen as unacceptable for the larger server platforms Itanium was targeting.[6] The effort to address these concerns was initially called Intel Boot Initiative, which began in 1998[7] and was later renamed EFI.[8][9]

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.[6][10]

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.

An overview of late 2011 usages of UEFI by independent hardware, BIOS, and software vendors.[11]

Contents

Interaction between the EFI boot manager and EFI drivers

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:[12]

  • Ability to boot from large disks (over 2 TiB) with a GUID Partition Table, GPT. [13][14]
  • Faster boot-up
  • CPU-independent architecture [13]
  • CPU-independent drivers [13]
  • Flexible pre-OS environment, including network capability
  • Modular design

Processor compatibility

As of version 2.3, processor bindings exist for Itanium, x86, x86_64 and ARM. Only little-endian processors can be supported.[15]

The 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.[6][16] In comparison, the UEFI processor mode can be either 32-bit (x86-32, ARM) or 64-bit (x86-64 and Itanium).[6][17] 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.[18]

UEFI requires the firmware and operating system to be size-matched; i.e. a 64-bit UEFI implementation can only boot a 64-bit UEFI operating system.

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 DOS MBR. In particular, the DOS MBR limits on the number and size of disk partitions (up to 4 partitions per disk, up to 2.2 TiB (241 bytes) per disk) are relaxed.[19] GPT allows for a maximum disk and partition size of 9.4 ZiB (273 bytes).[19][20] The EFI specification does not prescribe any particular file system. 64-bit versions of Microsoft Windows Vista and later, and the Itanium versions of Windows XP and Server 2003 can boot from disks partitioned to a size larger than 2.2 TiB.[clarification needed]

Services

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.

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.

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.[21] 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.[22]

Protocols

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.[23]

Booting

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 tables 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.

The EFI shell

EFI provides a shell environment.[24] The shell can be used to execute other EFI applications.

Extensions

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 the "TianoCore project." TianoCore can be used as a payload for coreboot [25].

Phoenix Technologies currently sells Phoenix SecureCore Tiano and Phoenix MicroCore Bios implementing UEFI.[26]

Aptio or Aptio 4 is American Megatrend's next-generation BIOS firmware based on UEFI and the Intel Platform Innovation Framework for UEFI/EFI.[27]

InsydeH2O is Insyde Software's implementation of the Intel Platform Innovation Framework for UEFI/EFI.[28]

Platforms using EFI/UEFI

Intel's first Itanium workstations and servers, released in 2000, implemented EFI 1.02.

Hewlett-Packard's first Itanium 2 systems, released in 2002, implemented EFI 1.10; they were able to boot Windows, Linux, FreeBSD and HP-UX; OpenVMS added UEFI capability in June, 2003.

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.[29] 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 the Framework.[30] New mobile, desktop and server products, using the Framework, started shipping in 2006. For instance, boards that use the Intel 945 chipset series use the Framework.

Since 2005, EFI has also been implemented on non-PC architectures, such as embedded systems based on XScale cores.[30]

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 have adopted UEFI. While many of these systems still allow booting only the BIOS-based OSes via the Compatibility Support Module (CSM) (thus does not appear to the user that the system is 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.[31] Many Sandy Bridge PC platforms use UEFI.

In 2011 ASRock, ASUSTeK, Gigabyte and MSI launched several consumer-based motherboards using the Intel 6-series LGA 1155 chipset and AMD 9 Series Chipset for Upcoming AM3+ AMD FX (Bulldozer) and AMD Fusion Processors with EFI.[32]

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.

  • Linux has been able to use EFI at boot time since early 2000,[citation needed] using the elilo EFI boot loader or, more recently, EFI versions of GRUB.[33] Grub+Linux also supports booting from a GUID partition table without UEFI.[14]
  • 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.[34]
  • Apple uses EFI for its line of Intel-based Macs. Mac OS X v10.4 Tiger for Intel and Mac OS X v10.5 Leopard implement EFI v1.10 in 32-bit mode, even on 64-bit CPUs (newer Macs have 64-bit EFI, but full support will not arrive until Mac OS X 10.8 Mountain Lion).[35]
  • 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.[36]
  • 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. Microsoft does not implement 32-bit UEFI since vendors did not have any interest in producing native 32-bit UEFI firmware because of the mainstream status of 64-bit computing.[37] Microsoft has released a video with Andrew Ritz and Jamie Schwartz explaining Pre-OS UEFI functions on Windows Vista and Windows Server 2008.[38]
  • Microsoft will demand that computers with the "Designed for Windows 8" logo to use UEFI with secure boot (which will only allow signed software to run on the device) enabled by default.[39][40] Red Hat developer Matthew Garrett raised concerns over the requirement for secure booting to be enabled by default and Microsoft responded by saying that there was no mandate from Microsoft that prevents secure booting from being disabled in firmware or that keys could not be updated and managed.[39][40]

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.[41]
  • 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,[42] but limited to Unix/Linux operating systems (doesn't work with Windows Vista x64 and Windows 7 x64).[43][44]
  • QEMU can be used with an EFI bios.
  • The VMware ESXi version 5 hypervisor, part of VMware vSphere, supports virtualized EFI as an alternative to BIOS inside a virtual machine.

Criticism

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 preserve “intellectual property” by removing the ability of the user to truly control his computer.[45][46] 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.[47]

TianoCore,[48] an open-source project which provides the UEFI interfaces, 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 chipset manufactures to cooperate by providing specifications needed to develop initialization drivers.

UEFI reimplements a full networking stack, unlike many BIOSes, and therefore is a target for remote security exploits.[49]

Secure Boot

See also: Windows 8#Secure boot and Hardware restrictions#Windows 8

Red Hat developer Matthew Garrett in his article "UEFI secure booting" raised a concern that UEFI "secure boot" feature may impact Linux (machines with the Windows 8 logo with secure boot enabled that ships with only OEM and Microsoft keys will not boot a generic copy of Linux).[50][51] In response, Microsoft stated that customers may be able to disable the secure boot feature in the UEFI interface.[2][52] Concern remained that some OEMs might omit that capability in their computers. Later it was reported that Microsoft apparently prohibited implementation of disabling of Secure Boot on ARM systems.[53][54]

Joshua Gay of the Free Software Foundation (FSF) raised concerns on "secure boot" implementation to UEFI and FSF declared a public statement open for signing which states:

We, the undersigned, urge all computer makers implementing UEFI's so-called "Secure Boot" to do it in a way that allows free software operating systems to be installed. To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice. We commit that we will neither purchase nor recommend computers that strip users of this critical freedom, and we will actively urge people in our communities to avoid such jailed systems.[55][56]

In December 2011, Microsoft released a document about hardware certification of OEM products, Windows Hardware Certification Requirements[57] which confirms that they intend to ban the possibility of installing alternative operating systems on ARM-based devices running Windows 8. The document insists that they will require x86 and x86-64 devices to have the Secure UEFI enabled. They allow for the possibility that a custom secure boot mode could be enabled providing to the user the ability to add signatures. However, they intend that going to custom secure boot mode or disabling secure boot mode on ARM devices will not be compatible with running Windows.[53]

See also

References

  1. ^ Michael Kinney (1 September 2000). "Solving BIOS Boot Issues with EFI" (PDF). pp. 47–50. Retrieved 14 September 2010.
  2. ^ a b . The Register. 23 September 2011. http://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/. Retrieved 24 September 2011.
  3. ^ "The 30-year-long Reign of BIOS is Over: Why UEFI W... - Input Output". H30565.www3.hp.com. Retrieved 2012-03-06.
  4. ^ https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html
  5. ^ 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.
  6. ^ a b c d "Emulex UEFI Implementation Delivers Industry-leading Features for IBM Systems" (PDF). Emulex. Retrieved 14 September 2010.
  7. ^ Extensible Firmware Interface (EFI) and Unified EFI (UEFI), Intel, archived from the original on 2010-01-05
  8. ^ Wei, Dong (2006), "foreword", Beyond BIOS, Intel Press, ISBN 978-0-9743649-0-2
  9. ^ "1.10 Specification overview", Extensible Firmware Interface, Intel
  10. ^ About, Unified EFI Forum, "Q: What is the relationship between EFI and UEFI? A: The UEFI specification will be 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 not be any 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 will come from the Forum, not from Intel"
  11. ^ UEFI Today: Bootstrapping the Continuum, Intel Press
  12. ^ "UEFI and Windows". Microsoft. 15 September 2009. Retrieved 14 September 2010.
  13. ^ a b c 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.
  14. ^ a b https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html -- grub 2 needs a special ~2MB partition on GUID dists to place itsself in in order to work, you can create this with gparted
  15. ^ UEFI specification 2.3.1, section 1.8.1.
  16. ^ Ben Hardwidge (1 June 2010). "LBA explained — Solving the 3TB Problem?". bit-tech. Retrieved 18 June 2010.
  17. ^ Brian Richardson (10 May 2010). "Ask a BIOS Guy: "Why UEFI"". Intel Architecture Blog. Retrieved 18 June 2010.
  18. ^ Gary Simpson. "UEFI Momentum — The AMD perspective" (PPTX). AMD. Retrieved 18 June 2010.
  19. ^ a b "FAQ: Drive Partition Limits" (PDF). UEFI Forum. Retrieved 9 June 2010.
  20. ^ 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."
  21. ^ UEFI specification, section 7.3
  22. ^ 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.
  23. ^ Intel shows PC booting Windows with UEFI firmware
  24. ^ Efi-shell.tianocore.org for EFI shell information
  25. ^ "TianoCore - coreboot". Retrieved 25 May 2012.
  26. ^ "SecureCore Tiano™". Phoenix Technologies, LTD. Retrieved 14 September 2010.
  27. ^ "Aptio®: The Complete UEFI Product Solution" (PDF). American Megatrends, Inc. Retrieved 8 January 2011.
  28. ^ "InsydeH2O UEFI Framework". Insyde Software Corp. Retrieved 8 January 2011.
  29. ^ Apple Computer. "Universal Binary Programming Guidelines, Second Edition: Extensible Firmware Interface (EFI)"
  30. ^ a b "Intel® Platform Innovation Framework for UEFI Overview". Intel. Retrieved 14 September 2010.
  31. ^ (PDF) Evaluating UEFI using Commercially Available Platforms and Solutions, UEFI, 2011‐5
  32. ^ Asus P67 Motherboard Preview, .
  33. ^ EFI version of Grub, Debian GNU/Linux, retrieved 1 May 2008
  34. ^ OpenVMS Release History, HP, retrieved 16 September 2008
  35. ^ rEFIt — Windows Vista and EFI, SourceForge
  36. ^ "Extensible Firmware Interface", Windows Server TechCenter, Microsoft
  37. ^ "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 has chosen not to ship support for 32-bit UEFI implementations."
  38. ^ "Pre-OS Video", MS Developers Network Channel 9, Microsoft
  39. ^ a b Jon Brodkin (21 September 2011). "Windows 8 secure boot could complicate Linux installs". Arstechnica. Retrieved 23 September 2011.
  40. ^ a b Denis Wong (22 September 2011). "Microsoft clarifies Windows 8 UEFI concerns". Neowin.net. Retrieved 23 September 2011.
  41. ^ Open Virtual Machine Firmware, SourceForge
  42. ^ 3.1 Changelog, VirtualBox
  43. ^ Ticket 7702, VirtualBox
  44. ^ "Statement by sr. software engineer at Oracle", Forum, VirtualBox
  45. ^ "Interview: Ronald G Minnich". Fosdem. 6 February 2007. Retrieved 14 September 2010.
  46. ^ , http://boingboing.net/2011/12/27/the-coming-war-on-general-purp.html
  47. ^ "coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware". YouTube. 31 October 2008. Retrieved 14 September 2010.
  48. ^ "Welcome", TianoCore, SourceForge
  49. ^ Risks, UK: NCL
  50. ^ Garrett, Matthew. "UEFI secure booting". Retrieved 20 September 2011.
  51. ^ Garrett, Matthew. "UEFI secure booting". Retrieved 23 September 2011.
  52. ^ "Protecting the pre-OS Environment with UEFI". Microsoft. 22 September 2011. Retrieved 24 September 2011.
  53. ^ a b "Microsoft confirms UEFI fears, locks down ARM devices - SFLC Blog - Software Freedom Law Center". Softwarefreedom.org. 2012-01-12. Retrieved 2012-03-06.
  54. ^ "Is Microsoft Blocking Linux Booting on ARM Hardware? - Open Enterprise". Blogs.computerworlduk.com. Retrieved 2012-03-06.
  55. ^ Gay, Josh. "Will your computer's "Secure Boot" turn out to be "Restricted Boot"?". www.fsf.org. Free Software Foundation. Retrieved 25 October 2011.
  56. ^ "Stand up for your freedom to install free software". www.fsf.org. Free Software Foundation. Retrieved 25 October 2011.
  57. ^ http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf

External links

 This article's use of external links may not follow Wikipedia's policies or guidelines. Please improve this article by removing excessive or inappropriate external links, and converting useful links where appropriate into footnote references. (April 2012)
http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

Implementing UEFI Secure Boot in Fedora

May. 30th, 2012 11:11 pm
mjg59Edit 16:17EDT 31/5/12: Clarification of who gets the $99
Edit 02:10EDT 01/6/12: Clarification that it's a one-off payment

(Brief disclaimer - while I work for Red Hat, I'm only going to be talking about Fedora here. Anything written below represents only my opinions and my work on Fedora, not Red Hat's opinions or future plans)

Fedora 17 was released this week. It's both useful and free, and serves as a welcome addition to any family gathering. Do give it a go. But it's also noteworthy for another reason - it's the last Fedora release in the pre-UEFI secure boot era. Fedora 18 will be released at around the same time as Windows 8, and as previously discussed all Windows 8 hardware will be shipping with secure boot enabled by default. While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora. We've been working on a plan for dealing with this. It's not ideal, but of all the approaches we've examined we feel that this one offers the best balance between letting users install Fedora while still permitting user freedom.

Getting the machine booted


Most hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key[1].

We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.

An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.

The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.

Bootloaders


We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.

What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.

Kernel


Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.

Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship, but what about out of tree drivers? We don't have a good answer for that yet. As before, we don't want any kind of solution that works for us but doesn't work for other distributions. Fedora-only or Ubuntu-only drivers are the last thing anyone wants, and this really needs to be handled in a cross-distribution way.

Wait signed what


Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.

But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.

And modules? Again, modules are just code. It's a little trickier, but if your signed kernel loads an unsigned module then that unsigned module can set up a fake UEFI environment and chain into a compromised OS bootloader. Now the attacker just has to include a signed kernel and a minimal initramfs that loads their malware module. It'd slow down boot by a couple of seconds, but other than that it'd be undetectable. X? If you can access the registers on a GPU then you can get the GPU to DMA over the kernel and execute arbitrary code. Trickier again, but still achievable - and if you've locked down every other avenue of attack, it's even attractive.

If we produce signed code that can be used to attack other operating systems then those other operating systems are justified in blacklisting us. That doesn't seem like a good outcome.

Customisation

Read More...
http://mjg59.dreamwidth.org/12368.html

Ubuntu ODM UEFI requirements for secure boot

Jun. 19th, 2012 11:46 am
mjg59Updated 22/06/2012: Reference to Canonical's response

A couple of people have asked me about the Ubuntu ODM UEFI requirements, specifically the secure boot section. This is aimed at hardware vendors who explicitly want to support Ubuntu, so it's not necessarily the approach Canonical will be taking for installing Ubuntu on average consumer hardware. But it's still worth looking at.

In a nutshell, the requirements for secure boot are:
  • The system must have an Ubuntu key preinstalled in each of KEK and db
  • It must be possible to disable secure boot
  • It must be possible for the end user to reconfigure keys

It's basically the same set of requirements as Microsoft have, except with an Ubuntu key instead of a Microsoft one.

Read More...
http://mjg59.dreamwidth.org/13713.html



Ubuntu BIOS/UEFI Requirements

1. Introduction
This document outlines a set of recommendations for system firmware teams producing both lega-
cy BIOS and UEFI firmware images for consumer systems, intended to be released with Ubuntu pre-
installed at the factory. The goal is to ensure that the system interoperates in a first-class manner
with Ubuntu, which may lead to eventual Ubuntu certification of the system(s).
The technical recommendations cover ACPI, WMI, SMM, hotkeys, video, and UEFI-specific details.
This document also covers the Ubuntu release cycle, including how Ubuntu incorporates the Linux
kernel. Finally, it discusses some of the tools that have been developed by Canonical and the Ubun-
tu Community for the purpose of debugging and/or qualifying BIOS / UEFI implementations.
2. Ubuntu development
Ubuntu releases new versions on a fixed six-month schedule. Ubuntu uses a release numbering con-
vention YY.MM, where YY is the last two digits of the year, and MM indicates the month of the re-
lease. At the time of writing, the current release of Ubuntu is 12.04, which was released in April
2012. Ubuntu releases also are given a two-word informal name, comprised of a fanciful or rare ani-
mal, and an adjective. The informal name for 12.04 is “Precise Pangolin”.
The current development version of Ubuntu is 12.10, codenamed “Quantal Quetzal”, and is sched-
uled for release in october 2012.
For more information on the Ubuntu release cycle, please refer to https://wiki.ubuntu.com/Re-
leaseSchedule
2.1. LTS releases
In addition to the regular six-month release cycle, Ubuntu also has a release cycle for Long Term
Support (LTS) releases. Every fourth Ubuntu release (which is every 2 years) is a LTS release. These
releases receive security updates for a longer period (5 years) than a normal Ubuntu release (18
months).
At the time of writing, the most recent LTS release is Ubuntu 12.04 LTS. The next development re-
lease will be 14.04.
Previously (up to and including the 10.04 release), LTS releases were supported for 3 years. This has
been extended to 5 years from the 12.04 release onwards.
For more information about Ubuntu LTS releases, please refer to: https://wiki.ubuntu.com/LTS

Read More (Download PDF)...
http://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf

From Arch Linux Wiki

Unified Extensible Firmware Interface (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 23 May 2012, UEFI Specification 2.3.1 is the most recent version.

Note: Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, these instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one UEFI Specification version and therefore it is not a standard UEFI firmware.

Booting an OS using BIOS

A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware are initialized and the POST operation is completed, the BIOS executes the first boot code in the first device in the device booting list.

If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.

Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.

Multiboot on BIOS

Since very little can be achieved by a program which fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like GRUB or GRUB2 or Syslinux or LILO would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.

Booting an OS using UEFI

UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems.

The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to support Apple Partition Map also apart from MBR and GPT. Most of the UEFI firmwares have support for accessing FAT12 (floppy disks) , FAT16 and FAT32 filesystems in HDD and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.

UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called "EFI SYSTEM PARTITION" in which files required to be launched by the firmware is stored. Each vendor can store its files under <EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/ folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.

Under UEFI, every program whether they are OS loaders or some utilities (like memory testing apps) or recovery tools outside the OS, should be a UEFI Application corresponding to the EFI firmware architecture. Most of the UEFI firmware in the market, including recent Apple Macs use x86_64 EFI firmware. Only some older macs use i386 EFI firmware while no non-Apple UEFI system is known to use i386 EFI firmware.

A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike the 64-bit Linux and Windows which include such support. Therefore the bootloader must be compiled for that architecture correctly.

Multibooting on UEFI

Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.

Linux Windows x86_64 UEFI-GPT Multiboot

Windows Vista (SP1+) and 7 pr 8 x86_64 versions support booting natively using UEFI firmware. But for this they need GPT partitioning of the disk used for UEFI booting. Windows x86_64 versions support either UEFI-GPT booting or BIOS-MBR booting. Windows 32-bit versions support only BIOS-MBR booting. Follow the instructions provided in the forum link given in the references sections as to how to do this. See http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 for more info.

This limitation does not exist in Linux Kernel but rather depends on the bootloader used. For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.

Boot Process under UEFI

  1. System switched on - POST process.
  2. UEFI firmware is loaded.
  3. Firmware reads its Boot Manager to determine which UEFI application to be launched and from where (ie. from which disk and partition).
  4. Firmware launches the UEFI application from the FAT32 formatted UEFISYS partition as defined in the boot entry in the firmware's boot manager.
  5. UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a bootloader like GRUB2) depending on how the UEFI application was configured.

Detecting UEFI Firmware Arch

If you have a non-mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI 2.x firmware.

Some of the known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio, Insyde H2O.

Some of the known systems using these firmwares are Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, many Intel Server and Desktop motherboards


Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.

To find out the arch of the efi firmware in a Mac, boot into Mac OS X and type the following command 

ioreg -l -p IODeviceTree | grep firmware-abi

If the command returns EFI32 the it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's efi implementation is not fully compliant with UEFI Specification.

UEFI Support in Linux Kernel

Linux Kernel config options for UEFI

Read More...
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_an_OS_using_UEFI

GUID Partition Table


GUID Partition Table (GPT) is a new style of partitioning which is part of the Unified Extensible Firmware Interface Specification, using the globally unique identifier for devices. It is different from the Master Boot Record (the more commonly used partitioning style) in many aspects and has many advantages.

To understand GPT, it is important to understand what is MBR and what are its disadvantages.

For any partitioning style, the number of partitions that can be defined is based on the total space allotted for the partition table and the space required for storing the information of a single partition.

Read More...
https://wiki.archlinux.org/index.php/GPT


Unified Extensible Firmware Interface (UEFI) - Windows 8 Secure Boot - Fedora and Ubuntu Linux Distros, Respond
Windows 8 Secure Boot: Two Linux Distros Respond | PCWorld Business Center
Fedora Linux 17 'Beefy Miracle' Makes Its Official Debut | PCWorld Business Center
Eight New Features in Ubuntu Linux 12.10 'Quantal Quetzal' Alpha 1 | PCWorld Business Center
R.I.P. BIOS: A UEFI Primer | PCWorld Business Center
Worried About Win 8 Secure Boot? So Is the Free Software Foundation | PCWorld Business Center
Linux Foundation: Secure Boot Need Not Be a Problem | PCWorld Business Center
mjg59 | Implementing UEFI Secure Boot in Fedora
Fedora Linux Capitulates to Microsoft Boot Certificate | PCWorld Business Center
ubuntu-bios-uefi-requirements.pdf (application/pdf Object)
mjg59 | Ubuntu ODM UEFI requirements for secure boot
Any comment on the Ubuntu UEFI ruckus?
PCH Search & Win: Unified Extensible Firmware Interface
Unified Extensible Firmware Interface - Wikipedia, the free encyclopedia
Extensible Firmware Interface (EFI) and Unified EFI (UEFI)
UEFI - Home
Unified Extensible Firmware Interface - ArchWiki
Unified Extensible Firmware Interface - ArchWiki
GUID Partition Table - ArchWiki
Windows’ Support for Disks with Capacity Greater than 2TB
PCH Search & Win: Unified Extensible Firmware Interface...
mjg59/shim · GitHub

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)