Slashdot Mirror

EFI is 20 years old, it's hardly a "new" standard. And if you look into current version's (UEFI) specification 12.3.1.2:
http://www.uefi.org/sites/defa...
you will see that filesystem used on ESP supports long file names.
So please stop disinformation.

I don't get any of it. Why does UEFI even exist?

Because BIOS sucks. It's a 16-bit relic carried over from the original IBM PC days that can't access anything more than 1MB of addressable space. It is incapable of doing things like initializing multiple devices at the same time, which makes booting very slow. It is x86 specific, meaning it won't work on Alpha, ARM, Itanium, or any other hardware platform. There are a few dozen other reasons as well, but you would be better served by google than me iterating them all.

I've never understood why people haven't implemented something lean and clean like OpenBoot/OpenFrimware on x86.

Why is OpenBoot/OpenFirmware better than UEFI? Both of those are untested an unsupported while tens of millions of devices are UEFI today, and have been working for the past 12+ years.

Yeah, I know there are working implementations out there, but it's not a standardized thing so it doesn't really matter.

What do you mean it's not a standardized thing? Of course it is. http://uefi.org/

So instead of having a nice firmware environment that is designed to boot the friggin' OS and get the hell out of the way, we've got this fucking monster of a firmware called UEFI that is essentially a pile of garbage with so much extraneous crap bolted on that it is frankly quite amazing. ... We should have a totally barebones firmware designed for booting things off media, and then an optional way to include stable storage on the motherboard for all the crap people might not want by default. Like an SD card, or hell- even a USB port. Lots of servers have internal USB ports that you can jam a key into to boot into a hypervisor or some other embedded OS.

Because people don't want barebones systems. They want to be able to do things like boot directly from CD/DVD/USB/SCSI. They want USB 2/3 drives to work and be bootable. Of course, all those things aren't "barebones", now are they? Barebones would mean it does the very basic minimum required by the majority of users. So it'll only boot if you have an NVidia card, using a PS/2 keyboard and mouse, off a Why the hell hasn't Microsoft been sued for antitrust again or something by requiring this rubbish on all the new computer?

Well for starters because Microsoft didn't write the UEFI standard. It was originally developed by Intel as the EFI standard, and then inherited by the UEFI group, which is made up of 11 different companies.

What boggles my mind is that it seems totally unnecessary. Why can't all the stupid Microsoft-centric bits reside on a USB key sticking out of the motherboard? Then if I don't want them, I don't need their "boot key" installed on the internal USB port.

There aren't any real "Microsoft-centric bits" inside UEFI. Some/many/most motherboard manufacturers include the 16? byte "key" from Microsoft so that they vast majority of users don't need to type it in to be able to enable Secure Boot on their system. You can delete this "HUGE" Microsoft-centric bit if you want to. You can disable Secure Boot if you want to. You can install any (or multiple) keys from anywhere (including yourself) if you want to. Now while I haven't tested every motherboard manufacturer out there, I can say for sure that these are all options on my own motherboard (ASUS Sabertooth X79), and I've never run into any UEFI motherboard in which these were not options.

The basis of your whole rant was that Microsoft invented this technology, but you were wrong. I suggest that you go read up on the UEFI before you start making these sorts of proclaimations. The standard was originally developed by Intel, not Microsoft, and they contributed the initial version to the UEFI Forum (which includes reprentatives from ten other companies other than Microsoft on their board).

I have no doubt that you will consider me to be a "Microsoft stooge" for pointing this out.

UEFI is a replacement for BIOS. As their web page puts it: The UEFI specification defines a new model for the interface between personal-computer operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications.

Secure boot is an optional feature of UEFI which can be used to ensure that the boot image being loaded by UEFI is from a trusted source.

The problems described in this article have nothing to do with secure boot.

Hello,

A list of OS software developers who are members of UEFI:

• Apple
• Canonical
• Cisco
• Cray
• Fujitsu
• Hewlett-Packard
• IBM
• Microsoft
• NEC
• Novell
• Oracle
• Red Flag
• Red Hat

And there are also other companies who work in the same neighborhood (CPU manufacturers, firmware developers, etc.). Source: UEFI Membership List.

While I understand (and, to some extent, sympathize with) the desire to hold Microsoft solely responsible for every activity in the computing industry, this is clearly a joint effort across the industry to replace a two decade-old invention whose time has come. And as far as I know, the largest installed base of UEFI firmware—albeit an older version of the standard—is Apple, a company not precisely known for having a cordial relationship with Microsoft.

Regards,

Aryeh Goretsky

I'm used to a little bit of healthy paranoia here, but the amount of FUD and flat-out misinformation in Slashdot's UEFI reporting is frankly astonishing. Let's get a few things straight.

UEFI is not a Microsoft technology. It is an industry standard intended intended to replace the archaic x86 BIOS. Microsoft participated in the standard, as did Slashdot favorites Red Hat, Canonical, IBM, and AMD. You can freely download the full specification from the uefi.org website.

Secure Boot is part of the larger UEFI specification. See section 27 for the technical details. Of particular interest to Slashdot readers will be section 27.7 which describes the key update mechanism.

Secure Boot is intended to solve the real-world security problem of boot-time malware. No operating system can defend against malware at boot-time; this would be equivalent to defending against the hardware itself. If it helps, imagine how you would defeat a keylogger embedded in your keyboard.

Secure Boot uses code-signing to defeat boot-time malware. This is the optimal solution and should be full-proof provided (1) the machine is physically secured, and (2) the private keys are secure. (I am defining "full-proof" here to mean the keys and hashes involved are adequately difficuly to brute-force with modern hardware. I am also explicitly discounting scenarios outside of UEFI's area-of-responsibility, such as vulnerabilities in the operating system's signed image.)

For some real irony, see the Slashdot article Windows 8 Secure Boot Defeated. Both the headline and much of the discussion in this article were flat-out wrong. The exploit in question targetted the legacy BIOS and MBR. This is exactly the problem that Secure Boot addresses, and it reinforces the need for this technology.

Secure Boot is not a DRM scheme, nor it is explicitly a tool for Microsoft lock-in. Remember that on x86 platforms, the end-user can edit the key database, and can disable Secure Boot entirely. I concur that Microsoft's treatment of ARM is a dick move, but is also typical for other vendors in that market segment. In either case, remember that Secure Boot is a logical solution to a real-world problem affecting all operating systems, and evaluate it on this merit first.

Just because the technology can be mis-used is no reason to completely boycott it. For my part, I intend to use Secure Boot when it becomes generally available, but only buy parts that allow me to edit the key database.

Links:
UEFI membership list: http://www.uefi.org/join/list/
UEFI specification: http://www.uefi.org/specs/agreement

I'm used to a little bit of healthy paranoia here, but the amount of FUD and flat-out misinformation in Slashdot's UEFI reporting is frankly astonishing. Let's get a few things straight.

UEFI is not a Microsoft technology. It is an industry standard intended intended to replace the archaic x86 BIOS. Microsoft participated in the standard, as did Slashdot favorites Red Hat, Canonical, IBM, and AMD. You can freely download the full specification from the uefi.org website.

Secure Boot is part of the larger UEFI specification. See section 27 for the technical details. Of particular interest to Slashdot readers will be section 27.7 which describes the key update mechanism.

Secure Boot is intended to solve the real-world security problem of boot-time malware. No operating system can defend against malware at boot-time; this would be equivalent to defending against the hardware itself. If it helps, imagine how you would defeat a keylogger embedded in your keyboard.

Secure Boot uses code-signing to defeat boot-time malware. This is the optimal solution and should be full-proof provided (1) the machine is physically secured, and (2) the private keys are secure. (I am defining "full-proof" here to mean the keys and hashes involved are adequately difficuly to brute-force with modern hardware. I am also explicitly discounting scenarios outside of UEFI's area-of-responsibility, such as vulnerabilities in the operating system's signed image.)

For some real irony, see the Slashdot article Windows 8 Secure Boot Defeated. Both the headline and much of the discussion in this article were flat-out wrong. The exploit in question targetted the legacy BIOS and MBR. This is exactly the problem that Secure Boot addresses, and it reinforces the need for this technology.

Secure Boot is not a DRM scheme, nor it is explicitly a tool for Microsoft lock-in. Remember that on x86 platforms, the end-user can edit the key database, and can disable Secure Boot entirely. I concur that Microsoft's treatment of ARM is a dick move, but is also typical for other vendors in that market segment. In either case, remember that Secure Boot is a logical solution to a real-world problem affecting all operating systems, and evaluate it on this merit first.

Just because the technology can be mis-used is no reason to completely boycott it. For my part, I intend to use Secure Boot when it becomes generally available, but only buy parts that allow me to edit the key database.

Links:
UEFI membership list: http://www.uefi.org/join/list/
UEFI specification: http://www.uefi.org/specs/agreement

I'm used to a little bit of healthy paranoia here, but the amount of FUD and flat-out misinformation in Slashdot's UEFI reporting is frankly astonishing. Let's get a few things straight.

UEFI is not a Microsoft technology. It is an industry standard intended intended to replace the archaic x86 BIOS. Microsoft participated in the standard, as did Slashdot favorites Red Hat, Canonical, IBM, and AMD. You can freely download the full specification from the uefi.org website.

Secure Boot is part of the larger UEFI specification. See section 27 for the technical details. Of particular interest to Slashdot readers will be section 27.7 which describes the key update mechanism.

Secure Boot is intended to solve the real-world security problem of boot-time malware. No operating system can defend against malware at boot-time; this would be equivalent to defending against the hardware itself. If it helps, imagine how you would defeat a keylogger embedded in your keyboard.

Secure Boot uses code-signing to defeat boot-time malware. This is the optimal solution and should be full-proof provided (1) the machine is physically secured, and (2) the private keys are secure. (I am defining "full-proof" here to mean the keys and hashes involved are adequately difficuly to brute-force with modern hardware. I am also explicitly discounting scenarios outside of UEFI's area-of-responsibility, such as vulnerabilities in the operating system's signed image.)

For some real irony, see the Slashdot article Windows 8 Secure Boot Defeated. Both the headline and much of the discussion in this article were flat-out wrong. The exploit in question targetted the legacy BIOS and MBR. This is exactly the problem that Secure Boot addresses, and it reinforces the need for this technology.

Secure Boot is not a DRM scheme, nor it is explicitly a tool for Microsoft lock-in. Remember that on x86 platforms, the end-user can edit the key database, and can disable Secure Boot entirely. I concur that Microsoft's treatment of ARM is a dick move, but is also typical for other vendors in that market segment. In either case, remember that Secure Boot is a logical solution to a real-world problem affecting all operating systems, and evaluate it on this merit first.

Just because the technology can be mis-used is no reason to completely boycott it. For my part, I intend to use Secure Boot when it becomes generally available, but only buy parts that allow me to edit the key database.

Links:
UEFI membership list: http://www.uefi.org/join/list/
UEFI specification: http://www.uefi.org/specs/agreement

It technically does still have an MBR called the Protective Master Boot Record or Protective MBR. This is part of the GUID Parition Table (GPT) standard. This data resides at Logical Block Address 0. So, your statement that "it doesn't exist is false." However, I believe that you are right, that he did not compromise UEFI. The article was not very clear, but he may be saying that he has been able to infect the PMBR of a GPT disk that boots from BIOS. That would make sense to me.

Also, before you decide to flame me for saying that you are incorrect, please read the spec. I know it is behind a form, but you can also read about it on wikipedia.

You could always go read the UEFI Specs to see if the UEFI folks have considered this. My guess is that they have already thought of this and it's answered in the specs somewhere.

http://www.uefi.org/learning_center/

Mod parent up. Please!

Yes, the I in (U)EFI stands for "interface", but this does *not* refer to a "user interface" but to a "software interface", like in API. The big deal about UEFI is *not* that MSI is going to replace the text-and-keyboard-based BIOS setup program with a GUI - proprietary vendors like Compaq have done this before as early as the 486 era (and then there was the AMI WinBios). The big deal is that the BIOS (note "BIOS" != "BIOS setup program") will be extended into something that has the potential to greatly facilitate the life of people who write kernels and drivers (i was going to say "kernel and driver hackers" but I'm not even sure that this crowd will understand hacker != cracker). From an (optimistic) user perspective, we might see less issues with buggy drivers and more cross-platform software in the future. Quoting from Wikipedia:
---
UEFI firmware provides several technical advantages:
        * Compatibility with operating systems that support only BIOS
        * Ability to boot from large disks
        * CPU-independent architecture
        * CPU-independent drivers
        * Flexible pre-OS environment
        * Modular design
---
http://en.wikipedia.org/wiki/UEFI
also see: http://www.uefi.org/about/

Just like parent, I can 't believe that I have to explain all this on ./
I officially proclaim this place dead. RIP.

I can't believe this is on /. This is completely wrong! BIOS Will not die, the UEFI Website itself says it. "Q: Does UEFI completely replace a PC BIOS? A: No. While UEFI uses a different interface for "boot services" and "runtime services", some platform firmware must perform the functions BIOS uses for system configuration (a.k.a. "Power On Self Test" or "POST") and Setup. UEFI does not specify how POST & Setup are implemented." -- From their website, if you don't believe me, http://www.uefi.org/about/ Please try to get your facts straight before posting.

If you want to "replace" the BIOS, write UEFI firmware, preferably 64-bit, based on the UEFI 2.1 specification. Anything else is already legacy.

Apple's computers are half way there, with 32-bit EFI 1.1, though I'd like to see a shell in firmware and a slightly better implementation of the legacy BIOS CSM.

The switch from PPC to intel was a far greater feat than going from Intel to AMD would be. In fact, I doubt there'd be a single software issue... apart from the lack of EFI (which I'm sure Apple could wrestle away from Intel at some outrageous price).

Actually, EFI is nowUEFI, and doesn't really belong to Intel anymore. In addition, AMD and Apple are members of the United EFI Forum.

Another reason for Apple not to buy AMD would be production issues - I believe one of the reasons Apple went with Intel was because of Intel's manufacturing capacity. If Apple buys AMD, they either don't get enough chips, or AMD CPUs become exclusive to Apple's computers - Dell, HP, and all the home builders would be SOL, because there'd be insufficient supply. And if that were to happen, there'd be zero benefit to owning AMD for Apple.

Another problem with this scenario is that Apple essentially buys ATI as well - what then, only ATI GPUs in Macs, in addition to only AMD CPUs? Then there's all the other chips AMD makes. Does Apple just sell off these other divisions, or just shut them down completely?

The switch from PPC to intel was a far greater feat than going from Intel to AMD would be. In fact, I doubt there'd be a single software issue... apart from the lack of EFI (which I'm sure Apple could wrestle away from Intel at some outrageous price).

Actually, EFI is nowUEFI, and doesn't really belong to Intel anymore. In addition, AMD and Apple are members of the United EFI Forum.

Another reason for Apple not to buy AMD would be production issues - I believe one of the reasons Apple went with Intel was because of Intel's manufacturing capacity. If Apple buys AMD, they either don't get enough chips, or AMD CPUs become exclusive to Apple's computers - Dell, HP, and all the home builders would be SOL, because there'd be insufficient supply. And if that were to happen, there'd be zero benefit to owning AMD for Apple.

Another problem with this scenario is that Apple essentially buys ATI as well - what then, only ATI GPUs in Macs, in addition to only AMD CPUs? Then there's all the other chips AMD makes. Does Apple just sell off these other divisions, or just shut them down completely?

Sweet OS indeed, late model Linux. But, whether we are talking about linux, winxp or vista, keep in mind that the OSs do not rely on the BIOS to initialize much hardware. Indeed, they will ignore most of the bios hardware preconfiguration and configure according to published specs. My new laptop, for instance, notifies me that the Pheonix bios contains PCI bios bug #81. Not a problem, since the kernel enumerates PCI devices itself.

This is one of the main things that made linuxbios possible! The amount of nondependant hardware initialization code in the linux kernel. Calling old world bios interrupt based functions can be more than a little tedious after you have jumped to 32 or even 64bit protected mode. Plans to do away with the old style bios have been underway for many years.

Sorry - I just assumed people would read up a bit before commenting.

Start here: http://www.uefi.org/

And then try here: http://en.wikipedia.org/wiki/Extensible_Firmware_I nterface

With support and innovation from all UEFI Forum member companies, work is being done continually to evolve the UEFI specification to meet industry needs.

What's wrong with the PC BIOS anyway? ... On a more sinister note, there's no mention in TFA of DRM and the idea of "trusted" computing.

According to the Overview page, Microsoft's listed as the only OS maker. First, why isn't Apple among the lineup? Novell? Red Hat Linux? Perhaps it's because they're not part of the real circle of friends...

Enter Microsoft's Trusted Computer Platform. According to the TCPA FAQ, the companies belonging to the alliance are: "Microsoft, Intel, IBM, HP and AMD". And let's take a look here...yep, they're all there. But what are they really planning?

According to the specifications page, nothing's listed as far as features that are to be included (" The UEFI specification is in development"). But currently, since there is no mention as to the true intent of this new technology, and right now the BIOS isn't broken, why reinvent the wheel? Load times are now less than three seconds, which is a tremendous step from BIOS beginnings. New equipment continues to be supported through new BIOS updates. So what do these companies need that the current BIOS can't give them?

Enter DRM. According to Microsoft's Patent on their DRM-supported OS, Microsoft has a few issues with the current BIOS...This AEGIS model requires a tamper-resistant BIOS that has hard-wired into it the signature of the following stage. This scheme has the very considerable advantage that it works well with current microprocessors and the current PC architecture, but has three drawbacks.

1) First, the set of trusted operating systems or trusted publishers must be wired into the BIOS.

2) Second, if the content is valuable enough (for instance, e-cash or Hollywood videos), users will find a way of replacing the BIOS with one that permits an insecure boot.

3) Third, when obtaining data from a network server, the client has no way of proving to the remote server that it is indeed running a trusted system.

So, Microsoft admits that there are flaws that prevent them from using the BIOS in their Trusted Computing platform. But create a new way of booting a computer, protect the technical details from public view, and put the power of the DMCA behind it, and you have a nice foundation into the DRM frontier.

What's wrong with the PC BIOS anyway? ... On a more sinister note, there's no mention in TFA of DRM and the idea of "trusted" computing.

According to the Overview page, Microsoft's listed as the only OS maker. First, why isn't Apple among the lineup? Novell? Red Hat Linux? Perhaps it's because they're not part of the real circle of friends...

Enter Microsoft's Trusted Computer Platform. According to the TCPA FAQ, the companies belonging to the alliance are: "Microsoft, Intel, IBM, HP and AMD". And let's take a look here...yep, they're all there. But what are they really planning?

According to the specifications page, nothing's listed as far as features that are to be included (" The UEFI specification is in development"). But currently, since there is no mention as to the true intent of this new technology, and right now the BIOS isn't broken, why reinvent the wheel? Load times are now less than three seconds, which is a tremendous step from BIOS beginnings. New equipment continues to be supported through new BIOS updates. So what do these companies need that the current BIOS can't give them?

Enter DRM. According to Microsoft's Patent on their DRM-supported OS, Microsoft has a few issues with the current BIOS...This AEGIS model requires a tamper-resistant BIOS that has hard-wired into it the signature of the following stage. This scheme has the very considerable advantage that it works well with current microprocessors and the current PC architecture, but has three drawbacks.

1) First, the set of trusted operating systems or trusted publishers must be wired into the BIOS.

2) Second, if the content is valuable enough (for instance, e-cash or Hollywood videos), users will find a way of replacing the BIOS with one that permits an insecure boot.

3) Third, when obtaining data from a network server, the client has no way of proving to the remote server that it is indeed running a trusted system.

So, Microsoft admits that there are flaws that prevent them from using the BIOS in their Trusted Computing platform. But create a new way of booting a computer, protect the technical details from public view, and put the power of the DMCA behind it, and you have a nice foundation into the DRM frontier.

What's wrong with the PC BIOS anyway? ... On a more sinister note, there's no mention in TFA of DRM and the idea of "trusted" computing.

According to the Overview page, Microsoft's listed as the only OS maker. First, why isn't Apple among the lineup? Novell? Red Hat Linux? Perhaps it's because they're not part of the real circle of friends...

Enter Microsoft's Trusted Computer Platform. According to the TCPA FAQ, the companies belonging to the alliance are: "Microsoft, Intel, IBM, HP and AMD". And let's take a look here...yep, they're all there. But what are they really planning?

According to the specifications page, nothing's listed as far as features that are to be included (" The UEFI specification is in development"). But currently, since there is no mention as to the true intent of this new technology, and right now the BIOS isn't broken, why reinvent the wheel? Load times are now less than three seconds, which is a tremendous step from BIOS beginnings. New equipment continues to be supported through new BIOS updates. So what do these companies need that the current BIOS can't give them?

Enter DRM. According to Microsoft's Patent on their DRM-supported OS, Microsoft has a few issues with the current BIOS...This AEGIS model requires a tamper-resistant BIOS that has hard-wired into it the signature of the following stage. This scheme has the very considerable advantage that it works well with current microprocessors and the current PC architecture, but has three drawbacks.

1) First, the set of trusted operating systems or trusted publishers must be wired into the BIOS.

2) Second, if the content is valuable enough (for instance, e-cash or Hollywood videos), users will find a way of replacing the BIOS with one that permits an insecure boot.

3) Third, when obtaining data from a network server, the client has no way of proving to the remote server that it is indeed running a trusted system.

So, Microsoft admits that there are flaws that prevent them from using the BIOS in their Trusted Computing platform. But create a new way of booting a computer, protect the technical details from public view, and put the power of the DMCA behind it, and you have a nice foundation into the DRM frontier.

Yes. You'll note that they're not listed as a member. Not invited? Not interested? Working on something else? Will they just license the developed tech from Intel? Who knows. But it's interesting that Dell is there but Apple is not.