10 ms·

UEFI boot: how does that actually work, then?

98 points by justincormack 12y ago

jhallenworld 12y ago
EFI Shell is the new (built-in) MS-DOS. I'm waiting for someone to make doom.efi :-) The the entire OS to BIOS API changed with UEFI. I've seen bugs where the BIOS int 15 ax=E820 memory map does not match the EFI memory map passed to Linux. All of this to support > 2TB drives.
- wtallis 12y ago
  EFI isn't about 2+TB drives. That's just GPT, which could have been implemented in a traditional BIOS. EFI was created because Intel needed something for the Itanium chips to run, and they didn't want to implement OpenFirmware. EFI came to the PC because Apple wasn't interested in starting a 16-bit 8086 programming division, and the rest of the industry followed suit because it was easier than squeezing more things into the 16-bit BIOS. Now that we've got both EFI and GPT widely available, we can have machines that can do things like fetch and install their own firmware updates and we can have sane dual-booting.
  - barrkel 12y ago
    However, in the meantime, we have to live with "complications" like a frequent lack of support on Linux for decent console drivers in UEFI boots. For example, technically the nVidia proprietary driver doesn't support framebuffer console on UEFI boots, and if you don't get the parameters just right, you can end up in the hilarious situation of typing your full disk encryption password blind to a blank screen visibly indistinguishable from a crashed bootloader.
    - yuhong 12y ago
      I have been saying that BIOSes needs a proper support lifecycle and bug reporting channel for both security and non-security bugs for a while now.
- geofft 12y ago
  You can find a python.efi from a few places like Tianocore... it's the new ROM BASIC.
- userbinator 12y ago
  I'm waiting for someone to make doom.efi It's been done: http://warfish.github.io/doom-uefi/ http://warfish.github.io/doom-uefi/ Source code is here: https://github.com/warfish/DOOM https://github.com/warfish/DOOM
pgeorgi 12y ago
Interesting overview. I just dislike how it sets the tone with the 'everything on the internet is crap except for what my Red Hat buddies and I say' intro which is then followed up with several minor inaccuracies in the text.
- naner 12y ago
  It was a pretty good overview, the secureboot stuff was needlessly condescending. Referring to UEFI as the "BIOS" is incorrect but is used commonly in the "IT World" (along with loads of other incorrect stuff...). The BIOS is understood as the thing where you configure basic hardware settings. I don't know if we're going to win that battle. The Windows equivalent of efibootmgr is bcdedit. It isn't well documented. In general, I think if you have the option to use UEFI and GPT they are better than the alternatives. I disable Secure Boot when installing Linux but I haven't installed it alongside Win 8 yet. The "you have to be in UEFI mode to install an UEFI-bootable OS" is an important point.
- crdoconnor 12y ago
  >I just dislike how it sets the tone with the 'everything on the internet is crap except for what my Red Hat buddies and I say' The UEFI world seems to be very clubby. I suspect its arcaneness and the lucrative nature of working in it contributes to this. I've seen this patronizing straw man "you don't know the spec like I do" from a few other UEFI blog posts, too.
crdoconnor 12y ago
>Most of the unhappiness about Secure Boot is not really about Secure Boot the mechanism – whether the people expressing that unhappiness think it is or not – but about specific implementations of Secure Boot in the real world. Unfortunately, people in the real world use implementations of secure boot, not its specification. >If you want to get cheap volume licenses of Windows from Microsoft to pre-install on your computers and have a nice “reassuring” ‘Microsoft Approved!’ sticker or whatever on the case, you have to comply with these requirements. That’s all the force they have. Post-US vs. Microsoft, MS does not want to be seen to be explicitly violating anti-trust law, which is why in public and on the record, they will say and do nothing wrong. This has actually done a lot of good, because it does shackle their ability to engage in anti-competitive behavior. It just doesn't shackle it completely, and it means that in order to do it they have to be a bit more creative. They still wield a large amount of power over the PC market, and manufacturers know this. They still have several ways of opaquely favoring or disfavoring some manufacturers over others. Manufacturers, on the whole, dont't mind being opaquely favored and don't want to be opaquely disfavored and know that crying foul about Microsoft abusing its market power in secret won't do them any favors either. It's a cut throat market and nobody is going to feel sorry for you as a manufacturer if you died out because you didn't get an Microsoft promotional tie in. Thus sometimes, all it takes for anti-trust violations to continue and to go unpunished is a nudge and a wink or an off the record conversation between MS and manufacturers, and a decision made by either party that falls in a gray area of legal defensibility. Here's where it gets evil, and here's the bit you are glossing over: Secure boot PROVIDES that gray area while maintaining a veneer of respectability. >If you have an x86 system that claims to be Windows certified but does not allow you to disable Secure Boot, it is in direct violation of the certification requirements, and you should certainly complain very loudly to someone. If a lot of these systems exist then we clearly have a problem and it might be time for that giant lawsuit, but so far I’m not aware of this being the case. All the x86-based, Windows-certified systems I’ve seen have had the ‘disable Secure Boot’ option in their firmwares. Certainly you seem to be able to turn it off in most implementations I've seen, but I haven't seen any that let me add trusted keys myself. Another gray area methinks. Nor is turning it off particularly easy. I know where it is and what it does, but I know the history behind it. MOST people draw a blank stare when they look at it and CERTAINLY don't get to the menu and look at it and think "oh, for sure this is the thing that stops me from installing linux". Oh, and incidentally I've never eer seen a coherent error message caused by secure boot's "protection". Not "you appear to be installing an untrusted OS". Just blank screens and opaque error messages. Let's say hypothetically that instead of being buried three menus deep, it was a physical switch, with a clear explanation about what it actually does. Let's say hypothetically that adding a key for secure boot were done using a clean and simple UI that my mother could follow. Flip the switch, plug in a USB key to boot from, menu asks if you want to trust this OS. You say yes and flip the switch back on. Let's say hypothetically that trying to install an "untrusted" OS gave you a clear error message. If these were the case (and these things certainly adhere to the spec), I wouldn't have a problem with it either. Let's be realistic, though. It's not that. It was not ever intended to be that. It was not supposed to be used to secure your system, and while Microsoft did just enough to avoid a lawsuit over it, their intentions are crystal clear. Hardware manufacturers also know what's up, and won't be making it an easy to use feature any time soon. MS is playing the same game they did pre-DOJ, they're just trying to keep plausible deniability at the same time as greasing all of the right palms. MS pretends not to violate antitrust law. Microsoft contributes to all the right election campaigns. DOJ pretends not to notice that Microsoft's secure boot initiative (if not the spec) is anti-competitive. >As far as x86 devices go, though, right now, Microsoft’s certification requirements actually explicitly protect your right to determine what can boot on your system. This is good. Microsoft is not explicitly breaking the law here. This is indeed good. Let's award them a fucking medal. By the way, I didn't deal drugs today. This is also good. As for UEFI itself - it reminds me of XML - designed by committee, and yes, strictly speaking it does do the job, but it's ridiculously overcomplicated and the market is littered with terrible implementations because of that complexity. Worst of all it was never truly necessary because a simpler specification (where's the UEFI equivalent of JSON?!) would have sufficed for all use cases. Another thing reminds me of XML too. There was a good market in being an expert in XML for a while. It was almost a club, in fact. The arcaneness plus the reliance the world had on it made for some excellent opportunities. Opportunities that, say, JSON never provided. There appears to be a good market to being the go to guy for UEFI too. Just sayin'
deleted 12y ago
[deleted]
orbifold 12y ago
I feel like Coreboot would be a much saner alternative to UEFI.
upofadown 12y ago
From this I get that "BIOS compatibility mode" is a required specification. Then I can ignore all the rest of the article. I have recently been learning about OpenBSD. I really like how they have handled all the weirdness associated with PC architecture booting/partitioning. OpenBSD simply ignores it and does everything on top of it. Once you have a partition marked as OpenBSD you are done the architecture specific stuff. Then you go on to do things the OpenBSD way which is the same over all architectures. So when Intel comes up with UUEFI (or whatever) you can continue to ignore the whole mess.
- ackalker 12y ago
  I very much doubt that just marking a partition as OpenBSD is the end of the architecture specific stuff. Somehow the firmware in your computer has to actually boot the OS. Unless things are setup in a way which is acceptable to the firmware with regards to booting (be it mandatory filesystems, directory structure and file formats, master boot records, partition table entries and corresponding flags, GUIDs, bootsectors, etc.), nothing much is going to happen when actually trying to boot it.
  - upofadown 12y ago
    Really. Once the OpenBSD partition boot sector gets control everything is done the OpenBSD way. There is some compatibility stuff for PC type partitions but it does not affect normal operation in any way. The GUIDs are the OpenBSD GUIDs. You don't even need a GPT for disks larger than 2GB because the OpenBSD stuff works up to 64PB.
- pgeorgi 12y ago
  Compatibility Support Modules ("BIOS compatibility mode") aren't required. The text states "many UEFI firmwares implement some kind of BIOS compatibility mode, sometimes referred to as a CSM.". "many" not "all", and the article sticks to that. Since CSMs are incompatible with Secure Boot (since they can run whatever, without extending the trust chain), I expect them to be on the way out. Same as with the "Secure Boot optional" requirement on x86, by the way, since I guess that the real reason Microsoft added that to their Windows Logo requirements is that their large customers wanted to be sure that they can image Windows 7 onto new machines for a while longer. Once this kind of legacy is gone for good, Microsoft may tighten the screws there. And since all big Linux vendors support Secure Boot now, that part of the PC landscape won't make many noises either.
rbanffy 12y ago
After fighting an eMMC-based "Windows Chromebook" for the last couple weeks, I think I can answer how its specific implementation of UEFI works with one word: "poorly".
- arthurfm 12y ago
  What were you trying to do with it?
  - rbanffy 12y ago
    I was trying to install Ubuntu so that it boots off the eMMC. No luck there, but Fedora can boot from a tiny USB stick that barely protrudes from the chassis.
ackalker 12y ago
From the article: "it’s a really good idea to go and read the UEFI specification. You can do this. It’s very easy. You don’t have to pay anyone any money. [...] You can find it [right here on the official UEFI site]. You have to check a couple of boxes, but you are not signing your soul away to Satan, or anything." Before people click on that link and start thinking the author of the article is a damn liar (the link takes one to a menacing "Access Denied" page which prompts users to login or register (which in turn involves filling out a form and possibly paying a large amount of money)), here is a link to free downloads of the specification documents (as PDF files): http://www.uefi.org/specifications http://www.uefi.org/specifications And by the way, no need to check any boxes at all, just click any of the links and the download should start right away.
- pgeorgi 12y ago
  But also read the blurb on the page: "By downloading any of the UEFI Specifications, you acknowledge that no license, express or implied, is granted to you to distribute, additionally reproduce, implement or otherwise use for any purpose (other than to read only) the UEFI Specifications, and that all rights, title and interest in and to the UEFI Specifications, including all intellectual property rights of any type whatsoever, are owned by the UEFI Forum, or subject to rights granted to the UEFI Forum." So if I download these files, I acknowledge that I may not use the spec to do anything useful with it. It might be better to derive UEFI knowledge from the Tianocore sources, since those come with no strings attached.
pudquick 12y ago
One piece that was not mentioned is the necessity of your UEFI / EFI implementation including integrated chipset driver support for talking to various devices (mass storage, USB, etc) at boot. Additionally how that can interact with legacy Option ROMs. It also didn't cover the replacement of the BIOS VGA baseline graphical communication standard with GOP (Graphics Output Protocol) - meaning that your graphics card itself specifically needs to be compatible with UEFI / EFI to even boot. I'm sad he took a negative stance to Apple in the article. Their implementation (of EFI) is very interesting in the choices they made and it's worth noting the differences (they do not, for instance, provide a graphical configuration choice "boot menu" like most PCs - they only provide visual boot media selection). Another interesting thing Apple did was, prior to all Windows editions natively booting to UEFI / EFI, they still wanted to provide dual boot support for OS X and Windows on their Intel Macs. But this meant that while OS X was EFI booting and required GPT drives - Windows was BIOS booting and required MBR drives. As such, Apple used a hybrid GPT/MBR format where the partition maps in both were in synchronization and GPT reserved the areas where MBR information was stored on the drive.
- cmurf 12y ago
  Apple makes some of the best and worse choices, often even simultaneously. Good: No firmware setup UI. Leave the user out of it. Good: Firmware built-in GUI boot manager that discovers currently bootable OS's dynamically. Plug in an external, an icon appears with an animated reveal. Animation in the f'n firmware built-in boot manager. Bad: That boot manager hard wires a label "Windows" for any legacy CSM-BIOS installed OS, even if it isn't Windows. Mixed: Apple's firmware is mainly based on Intel 1.10, with some extensions such as UEFI GOP, and some Apple stuff. It's not a standard UEFI 2.x firmware at all, and it's not documented at all. 3rd party bootloader programs have to have physical access to Macs to poke them with a stick in order to figure out how they work due to Apple's closed nature. So if you care about running open source OS's on Apple hardware, this is probably more "bad" than "mixed". Very bad: There's a long standing pernicious bug with Disk Utility, on Boot Camp'd drives (OS X + Windows) which permits the user to resize the OS X volume thereby creating a 5th partition: ESP, OS X, New Partition, Apple Boot, Windows. And Apple's tools remove the hybrid MBR, replace it with a protective MBR, and now Windows is unbootable. All without warning. This behavior violates their own proscription against manipulating drives with hybrid MBRs. Technote 2166: "If block 0 contains any other form of MBR, it should refuse to manipulate the disk." Their message boards have hundreds of such complaints. This isn't new, it's been a problem for years, it was bug reported years ago, and Apple basically blamed it on Windows rather than their own tool which actually causes the problem by wiping out the PMBR. https://developer.apple.com/library/mac/technotes/tn2166/_index.html#//apple_ref/doc/uid/DTS10003927-CH1-SUBSECTION11 https://developer.apple.com/library/mac/technotes/tn2166/_in... So I'm not a fan of their hybrid MBR hack, even though earlier on it was probably unavoidable. Windows has supported UEFI booting since Vista, but Apple's kinda dragged their feet on supporting UEFI Windows boot until very recently, and I'm not even certain Boot Camp Assistant defaults to this behavior yet.
bo1024 12y ago
As as someone who just wants to install the OSes of their choice on their machines, the main takeaway I got was > there used to be a thing called BIOS that was dead simple to deal with and did what you want. Now there is a replacement called UEFI that is insanely complicated to deal with and (at least in practice) makes it hard to do what you want. Is that accurate?
- josteink 12y ago
  Not really. I'd amend your statement to be "There used to be a very limited thing called BIOS, a collection of historical hacks, which only did one thing decently, but not really well. To make matters worse, in all cases but this one, it completely fell apart. There was no consistent tooling, and when it worked, it was non-inspectable black magic even to the most sophisticated power-user. The limitations of BIOS booting caused different OSes to constantly step on each others feet." UEFI is different, but actually has a design, supports tooling, any OS can work with it seamlessly without fear of collision, and as result it handles all scenarios simple or complex equally well. As a bonus it can also do a million things BIOS couldn't, like loading a Linux-kernel directly, from acoss the network, without any intermedia-bootloading proxy or iPXE shim. Now you can actually put your bootloader setup in source-control. I'm not sure why you would do that, but please go ahead and try that with BIOS. So yeah. UEFI really isn't that complex. It's just different. It just seems more complex because now even regular guys like us can see all the moving parts, where in the past only OS-designers could peek in.
  - epistasis 12y ago
    Really weird to see this downvoted. IMHO, UEFI is a godsend from the terrible BIOS days. Things like ipmitool could sometimes be used to control the BIOS on server hardware, but efibootmgr is much better, and available everywhere now.
    - josteink 12y ago
      If I were to take a guess, it would be that some people think the UEFI spec is over-complicated and tries to do too much things, and that the firmware-level is not where all these things should be done. It would have been fully possible to create something better than BIOS without (effectively) creating a new mini MS-DOS inside the machine firmware. The buggy UEFI firmwares some people has had to suffer also lends hand to that argument: A simpler specification would probably have caused people fewer issues. Sometimes less is more. I suspect UEFI would have been more warmly received had it taken a lower aim. It probably didn't help either that it was initially (wrongfully?) associated with Microsoft, and a hostile anti-Linux takeover of the X86 platform at firmware level.

98 points by justincormack 12y ago

EFI Shell is the new (built-in) MS-DOS. I'm waiting for someone to make doom.efi :-) The the entire OS to BIOS API changed with UEFI. I've seen bugs where the BIOS int 15 ax=E820 memory map does not match the EFI memory map passed to Linux. All of this to support > 2TB drives.

wtallis 12y ago
EFI isn't about 2+TB drives. That's just GPT, which could have been implemented in a traditional BIOS. EFI was created because Intel needed something for the Itanium chips to run, and they didn't want to implement OpenFirmware. EFI came to the PC because Apple wasn't interested in starting a 16-bit 8086 programming division, and the rest of the industry followed suit because it was easier than squeezing more things into the 16-bit BIOS. Now that we've got both EFI and GPT widely available, we can have machines that can do things like fetch and install their own firmware updates and we can have sane dual-booting.
- barrkel 12y ago
  However, in the meantime, we have to live with "complications" like a frequent lack of support on Linux for decent console drivers in UEFI boots. For example, technically the nVidia proprietary driver doesn't support framebuffer console on UEFI boots, and if you don't get the parameters just right, you can end up in the hilarious situation of typing your full disk encryption password blind to a blank screen visibly indistinguishable from a crashed bootloader.
  - yuhong 12y ago
    I have been saying that BIOSes needs a proper support lifecycle and bug reporting channel for both security and non-security bugs for a while now.
geofft 12y ago
You can find a python.efi from a few places like Tianocore... it's the new ROM BASIC.
userbinator 12y ago
I'm waiting for someone to make doom.efi It's been done: http://warfish.github.io/doom-uefi/ http://warfish.github.io/doom-uefi/ Source code is here: https://github.com/warfish/DOOM https://github.com/warfish/DOOM

pgeorgi 12y ago

Interesting overview. I just dislike how it sets the tone with the 'everything on the internet is crap except for what my Red Hat buddies and I say' intro which is then followed up with several minor inaccuracies in the text.

naner 12y ago
It was a pretty good overview, the secureboot stuff was needlessly condescending. Referring to UEFI as the "BIOS" is incorrect but is used commonly in the "IT World" (along with loads of other incorrect stuff...). The BIOS is understood as the thing where you configure basic hardware settings. I don't know if we're going to win that battle. The Windows equivalent of efibootmgr is bcdedit. It isn't well documented. In general, I think if you have the option to use UEFI and GPT they are better than the alternatives. I disable Secure Boot when installing Linux but I haven't installed it alongside Win 8 yet. The "you have to be in UEFI mode to install an UEFI-bootable OS" is an important point.
crdoconnor 12y ago
>I just dislike how it sets the tone with the 'everything on the internet is crap except for what my Red Hat buddies and I say' The UEFI world seems to be very clubby. I suspect its arcaneness and the lucrative nature of working in it contributes to this. I've seen this patronizing straw man "you don't know the spec like I do" from a few other UEFI blog posts, too.

crdoconnor 12y ago

>Most of the unhappiness about Secure Boot is not really about Secure Boot the mechanism – whether the people expressing that unhappiness think it is or not – but about specific implementations of Secure Boot in the real world. Unfortunately, people in the real world use implementations of secure boot, not its specification. >If you want to get cheap volume licenses of Windows from Microsoft to pre-install on your computers and have a nice “reassuring” ‘Microsoft Approved!’ sticker or whatever on the case, you have to comply with these requirements. That’s all the force they have. Post-US vs. Microsoft, MS does not want to be seen to be explicitly violating anti-trust law, which is why in public and on the record, they will say and do nothing wrong. This has actually done a lot of good, because it does shackle their ability to engage in anti-competitive behavior. It just doesn't shackle it completely, and it means that in order to do it they have to be a bit more creative. They still wield a large amount of power over the PC market, and manufacturers know this. They still have several ways of opaquely favoring or disfavoring some manufacturers over others. Manufacturers, on the whole, dont't mind being opaquely favored and don't want to be opaquely disfavored and know that crying foul about Microsoft abusing its market power in secret won't do them any favors either. It's a cut throat market and nobody is going to feel sorry for you as a manufacturer if you died out because you didn't get an Microsoft promotional tie in. Thus sometimes, all it takes for anti-trust violations to continue and to go unpunished is a nudge and a wink or an off the record conversation between MS and manufacturers, and a decision made by either party that falls in a gray area of legal defensibility. Here's where it gets evil, and here's the bit you are glossing over: Secure boot PROVIDES that gray area while maintaining a veneer of respectability. >If you have an x86 system that claims to be Windows certified but does not allow you to disable Secure Boot, it is in direct violation of the certification requirements, and you should certainly complain very loudly to someone. If a lot of these systems exist then we clearly have a problem and it might be time for that giant lawsuit, but so far I’m not aware of this being the case. All the x86-based, Windows-certified systems I’ve seen have had the ‘disable Secure Boot’ option in their firmwares. Certainly you seem to be able to turn it off in most implementations I've seen, but I haven't seen any that let me add trusted keys myself. Another gray area methinks. Nor is turning it off particularly easy. I know where it is and what it does, but I know the history behind it. MOST people draw a blank stare when they look at it and CERTAINLY don't get to the menu and look at it and think "oh, for sure this is the thing that stops me from installing linux". Oh, and incidentally I've never eer seen a coherent error message caused by secure boot's "protection". Not "you appear to be installing an untrusted OS". Just blank screens and opaque error messages. Let's say hypothetically that instead of being buried three menus deep, it was a physical switch, with a clear explanation about what it actually does. Let's say hypothetically that adding a key for secure boot were done using a clean and simple UI that my mother could follow. Flip the switch, plug in a USB key to boot from, menu asks if you want to trust this OS. You say yes and flip the switch back on. Let's say hypothetically that trying to install an "untrusted" OS gave you a clear error message. If these were the case (and these things certainly adhere to the spec), I wouldn't have a problem with it either. Let's be realistic, though. It's not that. It was not ever intended to be that. It was not supposed to be used to secure your system, and while Microsoft did just enough to avoid a lawsuit over it, their intentions are crystal clear. Hardware manufacturers also know what's up, and won't be making it an easy to use feature any time soon. MS is playing the same game they did pre-DOJ, they're just trying to keep plausible deniability at the same time as greasing all of the right palms. MS pretends not to violate antitrust law. Microsoft contributes to all the right election campaigns. DOJ pretends not to notice that Microsoft's secure boot initiative (if not the spec) is anti-competitive. >As far as x86 devices go, though, right now, Microsoft’s certification requirements actually explicitly protect your right to determine what can boot on your system. This is good. Microsoft is not explicitly breaking the law here. This is indeed good. Let's award them a fucking medal. By the way, I didn't deal drugs today. This is also good. As for UEFI itself - it reminds me of XML - designed by committee, and yes, strictly speaking it does do the job, but it's ridiculously overcomplicated and the market is littered with terrible implementations because of that complexity. Worst of all it was never truly necessary because a simpler specification (where's the UEFI equivalent of JSON?!) would have sufficed for all use cases. Another thing reminds me of XML too. There was a good market in being an expert in XML for a while. It was almost a club, in fact. The arcaneness plus the reliance the world had on it made for some excellent opportunities. Opportunities that, say, JSON never provided. There appears to be a good market to being the go to guy for UEFI too. Just sayin'

deleted 12y ago

[deleted]

orbifold 12y ago

I feel like Coreboot would be a much saner alternative to UEFI.

upofadown 12y ago

From this I get that "BIOS compatibility mode" is a required specification. Then I can ignore all the rest of the article. I have recently been learning about OpenBSD. I really like how they have handled all the weirdness associated with PC architecture booting/partitioning. OpenBSD simply ignores it and does everything on top of it. Once you have a partition marked as OpenBSD you are done the architecture specific stuff. Then you go on to do things the OpenBSD way which is the same over all architectures. So when Intel comes up with UUEFI (or whatever) you can continue to ignore the whole mess.

ackalker 12y ago
I very much doubt that just marking a partition as OpenBSD is the end of the architecture specific stuff. Somehow the firmware in your computer has to actually boot the OS. Unless things are setup in a way which is acceptable to the firmware with regards to booting (be it mandatory filesystems, directory structure and file formats, master boot records, partition table entries and corresponding flags, GUIDs, bootsectors, etc.), nothing much is going to happen when actually trying to boot it.
- upofadown 12y ago
  Really. Once the OpenBSD partition boot sector gets control everything is done the OpenBSD way. There is some compatibility stuff for PC type partitions but it does not affect normal operation in any way. The GUIDs are the OpenBSD GUIDs. You don't even need a GPT for disks larger than 2GB because the OpenBSD stuff works up to 64PB.
pgeorgi 12y ago
Compatibility Support Modules ("BIOS compatibility mode") aren't required. The text states "many UEFI firmwares implement some kind of BIOS compatibility mode, sometimes referred to as a CSM.". "many" not "all", and the article sticks to that. Since CSMs are incompatible with Secure Boot (since they can run whatever, without extending the trust chain), I expect them to be on the way out. Same as with the "Secure Boot optional" requirement on x86, by the way, since I guess that the real reason Microsoft added that to their Windows Logo requirements is that their large customers wanted to be sure that they can image Windows 7 onto new machines for a while longer. Once this kind of legacy is gone for good, Microsoft may tighten the screws there. And since all big Linux vendors support Secure Boot now, that part of the PC landscape won't make many noises either.

rbanffy 12y ago

After fighting an eMMC-based "Windows Chromebook" for the last couple weeks, I think I can answer how its specific implementation of UEFI works with one word: "poorly".

arthurfm 12y ago
What were you trying to do with it?
- rbanffy 12y ago
  I was trying to install Ubuntu so that it boots off the eMMC. No luck there, but Fedora can boot from a tiny USB stick that barely protrudes from the chassis.

ackalker 12y ago

From the article: "it’s a really good idea to go and read the UEFI specification. You can do this. It’s very easy. You don’t have to pay anyone any money. [...] You can find it [right here on the official UEFI site]. You have to check a couple of boxes, but you are not signing your soul away to Satan, or anything." Before people click on that link and start thinking the author of the article is a damn liar (the link takes one to a menacing "Access Denied" page which prompts users to login or register (which in turn involves filling out a form and possibly paying a large amount of money)), here is a link to free downloads of the specification documents (as PDF files): http://www.uefi.org/specifications http://www.uefi.org/specifications And by the way, no need to check any boxes at all, just click any of the links and the download should start right away.

pgeorgi 12y ago
But also read the blurb on the page: "By downloading any of the UEFI Specifications, you acknowledge that no license, express or implied, is granted to you to distribute, additionally reproduce, implement or otherwise use for any purpose (other than to read only) the UEFI Specifications, and that all rights, title and interest in and to the UEFI Specifications, including all intellectual property rights of any type whatsoever, are owned by the UEFI Forum, or subject to rights granted to the UEFI Forum." So if I download these files, I acknowledge that I may not use the spec to do anything useful with it. It might be better to derive UEFI knowledge from the Tianocore sources, since those come with no strings attached.

pudquick 12y ago

One piece that was not mentioned is the necessity of your UEFI / EFI implementation including integrated chipset driver support for talking to various devices (mass storage, USB, etc) at boot. Additionally how that can interact with legacy Option ROMs. It also didn't cover the replacement of the BIOS VGA baseline graphical communication standard with GOP (Graphics Output Protocol) - meaning that your graphics card itself specifically needs to be compatible with UEFI / EFI to even boot. I'm sad he took a negative stance to Apple in the article. Their implementation (of EFI) is very interesting in the choices they made and it's worth noting the differences (they do not, for instance, provide a graphical configuration choice "boot menu" like most PCs - they only provide visual boot media selection). Another interesting thing Apple did was, prior to all Windows editions natively booting to UEFI / EFI, they still wanted to provide dual boot support for OS X and Windows on their Intel Macs. But this meant that while OS X was EFI booting and required GPT drives - Windows was BIOS booting and required MBR drives. As such, Apple used a hybrid GPT/MBR format where the partition maps in both were in synchronization and GPT reserved the areas where MBR information was stored on the drive.

cmurf 12y ago
Apple makes some of the best and worse choices, often even simultaneously. Good: No firmware setup UI. Leave the user out of it. Good: Firmware built-in GUI boot manager that discovers currently bootable OS's dynamically. Plug in an external, an icon appears with an animated reveal. Animation in the f'n firmware built-in boot manager. Bad: That boot manager hard wires a label "Windows" for any legacy CSM-BIOS installed OS, even if it isn't Windows. Mixed: Apple's firmware is mainly based on Intel 1.10, with some extensions such as UEFI GOP, and some Apple stuff. It's not a standard UEFI 2.x firmware at all, and it's not documented at all. 3rd party bootloader programs have to have physical access to Macs to poke them with a stick in order to figure out how they work due to Apple's closed nature. So if you care about running open source OS's on Apple hardware, this is probably more "bad" than "mixed". Very bad: There's a long standing pernicious bug with Disk Utility, on Boot Camp'd drives (OS X + Windows) which permits the user to resize the OS X volume thereby creating a 5th partition: ESP, OS X, New Partition, Apple Boot, Windows. And Apple's tools remove the hybrid MBR, replace it with a protective MBR, and now Windows is unbootable. All without warning. This behavior violates their own proscription against manipulating drives with hybrid MBRs. Technote 2166: "If block 0 contains any other form of MBR, it should refuse to manipulate the disk." Their message boards have hundreds of such complaints. This isn't new, it's been a problem for years, it was bug reported years ago, and Apple basically blamed it on Windows rather than their own tool which actually causes the problem by wiping out the PMBR. https://developer.apple.com/library/mac/technotes/tn2166/_index.html#//apple_ref/doc/uid/DTS10003927-CH1-SUBSECTION11 https://developer.apple.com/library/mac/technotes/tn2166/_in... So I'm not a fan of their hybrid MBR hack, even though earlier on it was probably unavoidable. Windows has supported UEFI booting since Vista, but Apple's kinda dragged their feet on supporting UEFI Windows boot until very recently, and I'm not even certain Boot Camp Assistant defaults to this behavior yet.

bo1024 12y ago

As as someone who just wants to install the OSes of their choice on their machines, the main takeaway I got was > there used to be a thing called BIOS that was dead simple to deal with and did what you want. Now there is a replacement called UEFI that is insanely complicated to deal with and (at least in practice) makes it hard to do what you want. Is that accurate?

josteink 12y ago
Not really. I'd amend your statement to be "There used to be a very limited thing called BIOS, a collection of historical hacks, which only did one thing decently, but not really well. To make matters worse, in all cases but this one, it completely fell apart. There was no consistent tooling, and when it worked, it was non-inspectable black magic even to the most sophisticated power-user. The limitations of BIOS booting caused different OSes to constantly step on each others feet." UEFI is different, but actually has a design, supports tooling, any OS can work with it seamlessly without fear of collision, and as result it handles all scenarios simple or complex equally well. As a bonus it can also do a million things BIOS couldn't, like loading a Linux-kernel directly, from acoss the network, without any intermedia-bootloading proxy or iPXE shim. Now you can actually put your bootloader setup in source-control. I'm not sure why you would do that, but please go ahead and try that with BIOS. So yeah. UEFI really isn't that complex. It's just different. It just seems more complex because now even regular guys like us can see all the moving parts, where in the past only OS-designers could peek in.
- epistasis 12y ago
  Really weird to see this downvoted. IMHO, UEFI is a godsend from the terrible BIOS days. Things like ipmitool could sometimes be used to control the BIOS on server hardware, but efibootmgr is much better, and available everywhere now.
  - josteink 12y ago
    If I were to take a guess, it would be that some people think the UEFI spec is over-complicated and tries to do too much things, and that the firmware-level is not where all these things should be done. It would have been fully possible to create something better than BIOS without (effectively) creating a new mini MS-DOS inside the machine firmware. The buggy UEFI firmwares some people has had to suffer also lends hand to that argument: A simpler specification would probably have caused people fewer issues. Sometimes less is more. I suspect UEFI would have been more warmly received had it taken a lower aim. It probably didn't help either that it was initially (wrongfully?) associated with Microsoft, and a hostile anti-Linux takeover of the X86 platform at firmware level.