9 ms·

UEFI boot: how does that actually work, then? (2014)

164 points by luu 10y ago

mindslight 10y ago
> And no, Secure Boot itself is not evil. I am entirely comfortable stating this as a fact, and you should be too, unless you think GPG is evil Actually no, secure boot is evil, and comparing it to GPG is fallacious. The objection isn't to code signatures in general, but the inevitability of baked-in privileged keys inherent in its design. Calling it just an impartial mechanism is flat out naive, and the author even goes on to describe why: > But it’s worth noting it’s no more bad or wrong than most other major ARM platforms. Apple locks down the bootloader on all iDevices, and most Android devices also ship with locked bootloaders. While Microsoft exempts x64 hardware because they're concerned about further anti-trust action, the ARM ecosystem actually demonstrates the end result. By providing these companies the capability to lock things down, they inevitably will use it to enforce their inherent authoritarianism onto their customers. The majority of their customers will not care, accepting the age-old excuses for authoritarianism like "security". But capturing a pragmatic majority does not make something right, as apparent to anybody who struggled due to Microsoft's monopoly in its heyday. A freedom-preserving boot verification specification is definitely possible. In such, there must be no privileged key that cannot be disabled or augmented. Microsoft's x64 requirements do fulfill this, but as a result cause the system to fall to evil maid attacks. However, evil maid attacks can be prevented by incorporating an open-to-all proof-of-work / timed-lockout scheme. The core specification must incorporate this type of non-privileging scheme as a required element, to preempt any contractual requirements like Microsoft's.
- NeutronBoy 10y ago
  > Actually no, secure boot is evil, and comparing it to GPG is fallacious. The objection isn't to code signatures in general, but the inevitability of baked-in privileged keys inherent in its design. I mean, both my desktop and laptop have extensive BIOS options for key management - including removing the initial keys and loading your own.
  - mindslight 10y ago
    Yes, and this is actually encouraged by Microsoft to avoid anti-trust action. As I said, take a look at ARM for what an actual locked-down ecosystem looks like. Manufacturers inherently want to lock stuff down (for one, they sell more devices when someone wants to try out a new OS), but functionality being called a "standard" should actually be accessible to device purchasers.
    - johncolanduoni 10y ago
      Do you think their reaction to not having a standardized version would be "aw shucks, I guess we totally won't go with our own proprietary version then!"
      - mindslight 10y ago
        If markets were perfectly efficient, then we wouldn't be having this conversation. In reality defaults matter, whether for a manufacturer following a standard or a consumer buying an off the shelf PC.
- boomboomsubban 10y ago
  The author directly addresses this, and hits it dead on with >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 Maybe the UEFI specification should have implemented a way to distribute keys, though that would have been seen as a way to lock out smaller Linux distros. Maybe the ability to self sign keys should be part of the specs, I'm not sure it isn't, but that adds an additional security risk with fresh hardware.
  - mindslight 10y ago
    To me, creation and standardization of the capability is evil, even if it takes a further party's decision to cause actual effects. And I see those subsequent decisions as pretty inevitable, given how the market functions. I would draw an analog to surveillance. I have a problem with surveillance itself, even without the surveillance being used to facilitate any bad effects. Even just building the systems normalizes the paradigm and puts us in a precarious situation.
    - Hello71 10y ago
      a more precise analogy might be surveillance cameras. while an argument could be made for their immorality, the vast majority of society accepts at this point that while they can be used for bad (mass surveillance), their uses are varied and beneficial enough that we accept their costs as one of society's.
      - mindslight 10y ago
        What benefit [0] does anchoring the trust root to immutable keys [0] have over anchoring the trust root to a non-trapdoored proof of work? [0] Besides to a manufacturer, being able to retain control of hardware they do not own. [1] In a scheme anchored in specific keys, the keys must be immutable to prevent against evil maid.
    - boomboomsubban 10y ago
- Cyph0n 10y ago
  Maybe it's evil in consumer devices, but secure boot is very effective when you don't want people to tamper with your hardware, e.g., preventing counterfeit commercial-grade routers from entering the market. Cisco for example is facing a HUGE problem with counterfeits and is looking at secure boot as a potential solution. I'm not affiliated with Cisco, but I did attend a talk by one of their researchers at Georgia Tech.
  - mindslight 10y ago
    Secure boot solves the opposite problem from counterfeit hardware. If you make the hardware, you can insert whatever signing key you'd like - including Cisco's. This argument demonstrates why architecture is so insidious. Yes, "Secure Boot" solves real problems. As I said, these problems can be solved through similar functionality that does not anchor the trust root to private keys. But now that Microsoft (et al) have promulgated their naive fully-trusted-publisher implementations, we're left having to dispel the primacy of "keys" in the first place.
    - Cyph0n 10y ago
      I don't understand your point. You cannot "insert" Cisco's signing key into your own hardware because 1) the device does not possess it, and 2) only Cisco (ideally) has access to its signing key. If you instead mean that you can build your own custom hardware that mimics the functionality of Cisco's TPM and uses another key pair for signing boot code, then I give you a pat on the back for the accomplishment.
      - mindslight 10y ago
        Sorry, by "signing key" I meant "public part of the signing key", which is what is used for verification. Counterfeit hardware can also just ignore signatures on binaries. Presumably Cisco is really talking about using trusted hardware to preserve secrecy of their binaries (as the march of software eats their custom hardware, too). Which as I said, is possible to do without privileging specific signing keys.
- mwfunk 10y ago
  I can see why you as a consumer might not want hardware that you can't install custom software on. I can see why it might not be the best solution for legitimate non-nefarious engineering problems as well. What I've never related to, however, is the application of a moral dimension to someone selling such a thing. I'm all in favor of pragmatic arguments for openness and hackability for the sake of good engineering, transparency, generosity, customer expectations, etc. Those are all good things. I've never gotten the sense that the absence of those things are necessarily evil, however. You clearly do, based on your choice of words. Maybe that's the difference between the (for lack of a better term) BSD philosophy vs. RMS. The BSD (permissive?) philosophy seems rooted in the sense that sharing is a virtue, and not sharing is neutral (not necessarily evil). RMS' philosophy has always felt like, sharing is neutral, and not sharing is evil. It's a gross generalization, but copyleft vs. permissive reminds me of western vs. eastern religions. The FSF philosophy is defined by a large number of very strict thou shalt nots, defined as carefully and precisely as possible. Permissive licenses like BSD/MIT/Artistic/Apache/etc. are defined by their lack of conditions, which usually just amount to "do whatever you want, but you can't sue the author". Similarly, one of the ways western vs. eastern religions (from the outside looking in, at least) feel different is the focus on not being evil, by being aware of all of the behavioral laws you shouldn't violate, vs. the focus on trying to attain enlightenment by trying to elevate yourself. Stamping out bad behavior vs. encouraging good behavior. I see the merits of both, but for whatever reason the latter has always been much more relatable for me. I wonder if an individual's preference of copyleft vs. permissive is correlated with whether they think humans are inherently evil, vs. humans being inherently good or neutral. As cynical and pessimistic as I feel about humanity sometimes, deep down I do have a conviction that people are inherently good. It might be naive but I've never been able to totally shake it.
  - krylon 10y ago
    > "do whatever you want, but you can't sue the author" Do what thou wilt shall be the whole of the law, but thou shalt not sue me! ;-) SCNR!
  - mindslight 10y ago
    > Maybe that's the difference between the (for lack of a better term) BSD philosophy vs. RMS I like your characterization of this, but keep in mind you're proceeding to apply a moral dimension here ;) > I wonder if an individual's preference of copyleft vs. permissive is correlated with whether they think humans are inherently evil, vs. humans being inherently good or neutral. As cynical and pessimistic as I feel about humanity sometimes, deep down I do have a conviction that people are inherently good. Most people have an internal narrative whereby they are doing good, yet we still get emergent evil behavior. I tend to look at good/evil in terms of describing constructive end results, rather than as intent behind individual actions. Pragmatically, I'm seeing an awful lot of Free software that has been locked down through one scheme or another, making it non-Free for its end users. Since the intention of at least some of this software was to be Free for end users, I'd say nullifying that goal is moving in an evil direction. While fewer restrictions is indeed "simpler", such a regime isn't necessarily sufficient to achieve certain goals. When something is existentially defined as "base primitives", complexity will build on top of it to undermine the goals that fostered the axioms. Only by defining universal quantifications on behavior can specific qualities be preserved through time.
Peaker 10y ago
Excellent summary. A decade ago I was very well versed in how the bits and bytes of the MBR, partition table and BIOS boot process worked. Since then, I was completely out of the loop, and this filled me in.
boostedsignal 10y ago
I wrote a 5-minute tutorial on this (would appreciate feedback): http://www.boostedsignal.com/blog/a28c2988-151e-42cd-b0ab-1ce73bafa714.html http://www.boostedsignal.com/blog/a28c2988-151e-42cd-b0ab-1c...
- no_protocol 10y ago
  I like how it is concise and still seems to get the important points across. Well done.
  - boostedsignal 10y ago
    Thank you! That was my goal. I banged my head so much against the wall trying to understand the process, even though it should have been conceptually simple. If there are other topics (not necessarily computer-related) that you feel might benefit from a short explanation as well, feel free to let me know, and if I know about them I'd love to write about them.
AceJohnny2 10y ago
> Unless you’re dealing with Macs, and quite frankly, screw Macs. See also yesterday's story about the 2016 MBP not supporting Linux... https://news.ycombinator.com/item?id=12924051 https://news.ycombinator.com/item?id=12924051
- jlgaddis 10y ago
  You mean yesterday's story about Linux not supporting the latest MacBook Pro?
  - AceJohnny2 10y ago
    Yeah, that. Oops, looks like my phrasing got me downvotes. Oh well.
    - duncan_bayne 10y ago
      It got an upvote from me, for what that's worth.
userbinator 10y ago
IMHO UEFI is an overly complex solution that seems to be optimised for multibooting in various complex ways, a use-case that is probably extremely rare; how many "average users" do you know which have more than one OS natively installed on their machine? And of those, how many have more than two? Especially in this era of VMs, multibooting is becoming increasingly rare. On the other hand, BIOS boot is optimised for the overwhelmingly common case of one OS; select a boot device, load its first sector into memory, and jump to it. The BIOS does not need to know at all about filesystems, partitioning, or other things which are more at the OS level, which I think is a good application of the principle of "separation of concerns"; UEFI however seems to have become much of an OS itself, with all the associated complexity and increased failure modes of such. Two memorable incidents: https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=5139055 https://news.ycombinator.com/item?id=5139055 There is no BIOS specification. BIOS is a de facto standard – it works the way it worked on actual IBM PCs, in the 1980s. That’s kind of one of the reasons UEFI exists. It's more like a collection of specifications, but you can find much of the important ones here and much of the API is in the IBM PC/AT Technical Reference: http://cs.dartmouth.edu/~bx/blog/resources/bios.html http://cs.dartmouth.edu/~bx/blog/resources/bios.html The particularly relevant one for this article is here: http://www.phoenix.com/resources/specs-bbs101.pdf http://www.phoenix.com/resources/specs-bbs101.pdf (Note the URL and the date of the document.) The design doesn’t provide a standard way of booting from anything except disks. We’re not going to really talk about that in this article, but just be aware it’s another advantage of UEFI booting: it provides a standard way for booting from, for instance, a remote server. Network booting in the BIOS world is almost always done through PXE.
- drvdevd 10y ago
  Thats interesting. I've booted UEFI machines using PXE and judging from the PXE ROM versions displayed, the PXE code hasn't changed much, on my boxes at least. I would agree that UEFI is an OS of its' own. But thats the whole point isn't it? That way writing drivers for peripherals can be done in C, etc. I have a BIOS machine I cant boot using my SD card for example, which I need to do. I imagine writing (or porting) a driver for UEFI to interface with that SD card reader would be an order of magnitude simpler than doing the same by modifying my BIOS (which I've seriously considered doing).
Avernar 10y ago
The flaw with UEFI is that the list of installed operating systems is stored in the motherboard's NVRAM and not in the EFI system partion on the disk itself. When your motherboard dies and you need to put in a new one, now you have to boot off a CD/DVD/USB Stick to get to the boot manager utility. Then you have to figure out the command line parameters since the first time the OS installer did it for you. At minimum the motherboard setup menu should give you FULL editing cabability of the NVRAM variables. I should be able to add, modify and delete any and all entries without having to boot something first. Last motherboard I tried using the efibootmgr on got bricked. And there was no way to clear it like you can with normal BIOS NVRAM.
- rwmj 10y ago
  This is nonsense. UEFI has a fallback path and all common OSes can or do install a fallback bootloader which restores the NVRAM variables.
  - Avernar 10y ago
    You may not agree with me but don't call it nonsense. From the article about the fallback path: "This mechanism is not designed for booting permanently-installed OSes." Plus there is only one fallback path so we're back to the situation of multiple OSes fighting over the fallback path. And from the article a disadvantage of the BIOS: "It’s inconvenient to deal with – you need special utilities to write the MBR, and just about the only way to find out what’s in one is to dd the contents out and examine them." But now with UEFI we need a special utility to manipulate the EFI NVRAM variables. The motherboard setup only lists the names of the entries. No editing and no listing of the details. So my criticism is valid. The information stored in the UEFI bootmanager NVRAM should have been in a file(s) in the system partition.
ciupicri 10y ago
2014
jaclaz 10y ago
With all due respect for the Author (the article is seemingly a very nice one) there is the everstanding confusion between disk and partition/volume. I had hoped that - particularly for something intended to explain things - I would have had not to read "format a disk". Just in case, a disk is partitioned (in either MBR or GPT "style"), and the partition(s) or volume(s) on it thus created are later formatted with a given file system.
- wereHamster 10y ago
  You can certainly format a whole disk. I did it, the disk in my laptop doesn't have a partition table at all. The whole disk is one big encrypted filesystem. The laptop boots off of an external USB stick.
  - jaclaz 10y ago
    Sure you can, but that disk won't be bootable in UEFI (it may still be in BIOS). The article is about UEFI booting, with parted he checks the partitioning "style", not the actual formatting. >See that Partition table: msdos? This is an MBR/MS-DOS formatted disk. If it was GPT-formatted, that would say gpt.
laacz 10y ago
Read was interesting, but I found myself pushing through by force of curiosity. It was hard, since the post itself was very agressive to me - the reader.

164 points by luu 10y ago

> And no, Secure Boot itself is not evil. I am entirely comfortable stating this as a fact, and you should be too, unless you think GPG is evil Actually no, secure boot is evil, and comparing it to GPG is fallacious. The objection isn't to code signatures in general, but the inevitability of baked-in privileged keys inherent in its design. Calling it just an impartial mechanism is flat out naive, and the author even goes on to describe why: > But it’s worth noting it’s no more bad or wrong than most other major ARM platforms. Apple locks down the bootloader on all iDevices, and most Android devices also ship with locked bootloaders. While Microsoft exempts x64 hardware because they're concerned about further anti-trust action, the ARM ecosystem actually demonstrates the end result. By providing these companies the capability to lock things down, they inevitably will use it to enforce their inherent authoritarianism onto their customers. The majority of their customers will not care, accepting the age-old excuses for authoritarianism like "security". But capturing a pragmatic majority does not make something right, as apparent to anybody who struggled due to Microsoft's monopoly in its heyday. A freedom-preserving boot verification specification is definitely possible. In such, there must be no privileged key that cannot be disabled or augmented. Microsoft's x64 requirements do fulfill this, but as a result cause the system to fall to evil maid attacks. However, evil maid attacks can be prevented by incorporating an open-to-all proof-of-work / timed-lockout scheme. The core specification must incorporate this type of non-privileging scheme as a required element, to preempt any contractual requirements like Microsoft's.

NeutronBoy 10y ago
> Actually no, secure boot is evil, and comparing it to GPG is fallacious. The objection isn't to code signatures in general, but the inevitability of baked-in privileged keys inherent in its design. I mean, both my desktop and laptop have extensive BIOS options for key management - including removing the initial keys and loading your own.
- mindslight 10y ago
  Yes, and this is actually encouraged by Microsoft to avoid anti-trust action. As I said, take a look at ARM for what an actual locked-down ecosystem looks like. Manufacturers inherently want to lock stuff down (for one, they sell more devices when someone wants to try out a new OS), but functionality being called a "standard" should actually be accessible to device purchasers.
  - johncolanduoni 10y ago
    Do you think their reaction to not having a standardized version would be "aw shucks, I guess we totally won't go with our own proprietary version then!"
    - mindslight 10y ago
      If markets were perfectly efficient, then we wouldn't be having this conversation. In reality defaults matter, whether for a manufacturer following a standard or a consumer buying an off the shelf PC.
boomboomsubban 10y ago
The author directly addresses this, and hits it dead on with >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 Maybe the UEFI specification should have implemented a way to distribute keys, though that would have been seen as a way to lock out smaller Linux distros. Maybe the ability to self sign keys should be part of the specs, I'm not sure it isn't, but that adds an additional security risk with fresh hardware.
- mindslight 10y ago
  To me, creation and standardization of the capability is evil, even if it takes a further party's decision to cause actual effects. And I see those subsequent decisions as pretty inevitable, given how the market functions. I would draw an analog to surveillance. I have a problem with surveillance itself, even without the surveillance being used to facilitate any bad effects. Even just building the systems normalizes the paradigm and puts us in a precarious situation.
  - Hello71 10y ago
    a more precise analogy might be surveillance cameras. while an argument could be made for their immorality, the vast majority of society accepts at this point that while they can be used for bad (mass surveillance), their uses are varied and beneficial enough that we accept their costs as one of society's.
    - mindslight 10y ago
      What benefit [0] does anchoring the trust root to immutable keys [0] have over anchoring the trust root to a non-trapdoored proof of work? [0] Besides to a manufacturer, being able to retain control of hardware they do not own. [1] In a scheme anchored in specific keys, the keys must be immutable to prevent against evil maid.
  - boomboomsubban 10y ago
Cyph0n 10y ago
Maybe it's evil in consumer devices, but secure boot is very effective when you don't want people to tamper with your hardware, e.g., preventing counterfeit commercial-grade routers from entering the market. Cisco for example is facing a HUGE problem with counterfeits and is looking at secure boot as a potential solution. I'm not affiliated with Cisco, but I did attend a talk by one of their researchers at Georgia Tech.
- mindslight 10y ago
  Secure boot solves the opposite problem from counterfeit hardware. If you make the hardware, you can insert whatever signing key you'd like - including Cisco's. This argument demonstrates why architecture is so insidious. Yes, "Secure Boot" solves real problems. As I said, these problems can be solved through similar functionality that does not anchor the trust root to private keys. But now that Microsoft (et al) have promulgated their naive fully-trusted-publisher implementations, we're left having to dispel the primacy of "keys" in the first place.
  - Cyph0n 10y ago
    I don't understand your point. You cannot "insert" Cisco's signing key into your own hardware because 1) the device does not possess it, and 2) only Cisco (ideally) has access to its signing key. If you instead mean that you can build your own custom hardware that mimics the functionality of Cisco's TPM and uses another key pair for signing boot code, then I give you a pat on the back for the accomplishment.
    - mindslight 10y ago
      Sorry, by "signing key" I meant "public part of the signing key", which is what is used for verification. Counterfeit hardware can also just ignore signatures on binaries. Presumably Cisco is really talking about using trusted hardware to preserve secrecy of their binaries (as the march of software eats their custom hardware, too). Which as I said, is possible to do without privileging specific signing keys.
mwfunk 10y ago
I can see why you as a consumer might not want hardware that you can't install custom software on. I can see why it might not be the best solution for legitimate non-nefarious engineering problems as well. What I've never related to, however, is the application of a moral dimension to someone selling such a thing. I'm all in favor of pragmatic arguments for openness and hackability for the sake of good engineering, transparency, generosity, customer expectations, etc. Those are all good things. I've never gotten the sense that the absence of those things are necessarily evil, however. You clearly do, based on your choice of words. Maybe that's the difference between the (for lack of a better term) BSD philosophy vs. RMS. The BSD (permissive?) philosophy seems rooted in the sense that sharing is a virtue, and not sharing is neutral (not necessarily evil). RMS' philosophy has always felt like, sharing is neutral, and not sharing is evil. It's a gross generalization, but copyleft vs. permissive reminds me of western vs. eastern religions. The FSF philosophy is defined by a large number of very strict thou shalt nots, defined as carefully and precisely as possible. Permissive licenses like BSD/MIT/Artistic/Apache/etc. are defined by their lack of conditions, which usually just amount to "do whatever you want, but you can't sue the author". Similarly, one of the ways western vs. eastern religions (from the outside looking in, at least) feel different is the focus on not being evil, by being aware of all of the behavioral laws you shouldn't violate, vs. the focus on trying to attain enlightenment by trying to elevate yourself. Stamping out bad behavior vs. encouraging good behavior. I see the merits of both, but for whatever reason the latter has always been much more relatable for me. I wonder if an individual's preference of copyleft vs. permissive is correlated with whether they think humans are inherently evil, vs. humans being inherently good or neutral. As cynical and pessimistic as I feel about humanity sometimes, deep down I do have a conviction that people are inherently good. It might be naive but I've never been able to totally shake it.
- krylon 10y ago
  > "do whatever you want, but you can't sue the author" Do what thou wilt shall be the whole of the law, but thou shalt not sue me! ;-) SCNR!
- mindslight 10y ago
  > Maybe that's the difference between the (for lack of a better term) BSD philosophy vs. RMS I like your characterization of this, but keep in mind you're proceeding to apply a moral dimension here ;) > I wonder if an individual's preference of copyleft vs. permissive is correlated with whether they think humans are inherently evil, vs. humans being inherently good or neutral. As cynical and pessimistic as I feel about humanity sometimes, deep down I do have a conviction that people are inherently good. Most people have an internal narrative whereby they are doing good, yet we still get emergent evil behavior. I tend to look at good/evil in terms of describing constructive end results, rather than as intent behind individual actions. Pragmatically, I'm seeing an awful lot of Free software that has been locked down through one scheme or another, making it non-Free for its end users. Since the intention of at least some of this software was to be Free for end users, I'd say nullifying that goal is moving in an evil direction. While fewer restrictions is indeed "simpler", such a regime isn't necessarily sufficient to achieve certain goals. When something is existentially defined as "base primitives", complexity will build on top of it to undermine the goals that fostered the axioms. Only by defining universal quantifications on behavior can specific qualities be preserved through time.

Peaker 10y ago

Excellent summary. A decade ago I was very well versed in how the bits and bytes of the MBR, partition table and BIOS boot process worked. Since then, I was completely out of the loop, and this filled me in.

boostedsignal 10y ago

I wrote a 5-minute tutorial on this (would appreciate feedback): http://www.boostedsignal.com/blog/a28c2988-151e-42cd-b0ab-1ce73bafa714.html http://www.boostedsignal.com/blog/a28c2988-151e-42cd-b0ab-1c...

no_protocol 10y ago
I like how it is concise and still seems to get the important points across. Well done.
- boostedsignal 10y ago
  Thank you! That was my goal. I banged my head so much against the wall trying to understand the process, even though it should have been conceptually simple. If there are other topics (not necessarily computer-related) that you feel might benefit from a short explanation as well, feel free to let me know, and if I know about them I'd love to write about them.

AceJohnny2 10y ago

> Unless you’re dealing with Macs, and quite frankly, screw Macs. See also yesterday's story about the 2016 MBP not supporting Linux... https://news.ycombinator.com/item?id=12924051 https://news.ycombinator.com/item?id=12924051

jlgaddis 10y ago
You mean yesterday's story about Linux not supporting the latest MacBook Pro?
- AceJohnny2 10y ago
  Yeah, that. Oops, looks like my phrasing got me downvotes. Oh well.
  - duncan_bayne 10y ago
    It got an upvote from me, for what that's worth.

userbinator 10y ago

IMHO UEFI is an overly complex solution that seems to be optimised for multibooting in various complex ways, a use-case that is probably extremely rare; how many "average users" do you know which have more than one OS natively installed on their machine? And of those, how many have more than two? Especially in this era of VMs, multibooting is becoming increasingly rare. On the other hand, BIOS boot is optimised for the overwhelmingly common case of one OS; select a boot device, load its first sector into memory, and jump to it. The BIOS does not need to know at all about filesystems, partitioning, or other things which are more at the OS level, which I think is a good application of the principle of "separation of concerns"; UEFI however seems to have become much of an OS itself, with all the associated complexity and increased failure modes of such. Two memorable incidents: https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=5139055 https://news.ycombinator.com/item?id=5139055 There is no BIOS specification. BIOS is a de facto standard – it works the way it worked on actual IBM PCs, in the 1980s. That’s kind of one of the reasons UEFI exists. It's more like a collection of specifications, but you can find much of the important ones here and much of the API is in the IBM PC/AT Technical Reference: http://cs.dartmouth.edu/~bx/blog/resources/bios.html http://cs.dartmouth.edu/~bx/blog/resources/bios.html The particularly relevant one for this article is here: http://www.phoenix.com/resources/specs-bbs101.pdf http://www.phoenix.com/resources/specs-bbs101.pdf (Note the URL and the date of the document.) The design doesn’t provide a standard way of booting from anything except disks. We’re not going to really talk about that in this article, but just be aware it’s another advantage of UEFI booting: it provides a standard way for booting from, for instance, a remote server. Network booting in the BIOS world is almost always done through PXE.

drvdevd 10y ago
Thats interesting. I've booted UEFI machines using PXE and judging from the PXE ROM versions displayed, the PXE code hasn't changed much, on my boxes at least. I would agree that UEFI is an OS of its' own. But thats the whole point isn't it? That way writing drivers for peripherals can be done in C, etc. I have a BIOS machine I cant boot using my SD card for example, which I need to do. I imagine writing (or porting) a driver for UEFI to interface with that SD card reader would be an order of magnitude simpler than doing the same by modifying my BIOS (which I've seriously considered doing).

Avernar 10y ago

The flaw with UEFI is that the list of installed operating systems is stored in the motherboard's NVRAM and not in the EFI system partion on the disk itself. When your motherboard dies and you need to put in a new one, now you have to boot off a CD/DVD/USB Stick to get to the boot manager utility. Then you have to figure out the command line parameters since the first time the OS installer did it for you. At minimum the motherboard setup menu should give you FULL editing cabability of the NVRAM variables. I should be able to add, modify and delete any and all entries without having to boot something first. Last motherboard I tried using the efibootmgr on got bricked. And there was no way to clear it like you can with normal BIOS NVRAM.

rwmj 10y ago
This is nonsense. UEFI has a fallback path and all common OSes can or do install a fallback bootloader which restores the NVRAM variables.
- Avernar 10y ago
  You may not agree with me but don't call it nonsense. From the article about the fallback path: "This mechanism is not designed for booting permanently-installed OSes." Plus there is only one fallback path so we're back to the situation of multiple OSes fighting over the fallback path. And from the article a disadvantage of the BIOS: "It’s inconvenient to deal with – you need special utilities to write the MBR, and just about the only way to find out what’s in one is to dd the contents out and examine them." But now with UEFI we need a special utility to manipulate the EFI NVRAM variables. The motherboard setup only lists the names of the entries. No editing and no listing of the details. So my criticism is valid. The information stored in the UEFI bootmanager NVRAM should have been in a file(s) in the system partition.

ciupicri 10y ago

2014

jaclaz 10y ago

With all due respect for the Author (the article is seemingly a very nice one) there is the everstanding confusion between disk and partition/volume. I had hoped that - particularly for something intended to explain things - I would have had not to read "format a disk". Just in case, a disk is partitioned (in either MBR or GPT "style"), and the partition(s) or volume(s) on it thus created are later formatted with a given file system.

wereHamster 10y ago
You can certainly format a whole disk. I did it, the disk in my laptop doesn't have a partition table at all. The whole disk is one big encrypted filesystem. The laptop boots off of an external USB stick.
- jaclaz 10y ago
  Sure you can, but that disk won't be bootable in UEFI (it may still be in BIOS). The article is about UEFI booting, with parted he checks the partitioning "style", not the actual formatting. >See that Partition table: msdos? This is an MBR/MS-DOS formatted disk. If it was GPT-formatted, that would say gpt.

laacz 10y ago

Read was interesting, but I found myself pushing through by force of curiosity. It was hard, since the post itself was very agressive to me - the reader.