Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Intel Hardware

Demystifying UEFI, the Overdue BIOS Replacement 379

An anonymous reader writes "After more than 30 years of unerring and yet surprising supremacy, BIOS is taking its final bows. Taking its place is UEFI, a specification that begun its life as the Intel Boot Initiative way back in 1998 when BIOS's antiquated limitations were hampering systems built with Intel's Itanium processors. UEFI, as the article explains, is a complete re-imagining of a computer boot environment, and as such it has almost no similarities to the PC BIOS that it replaces."
This discussion has been archived. No new comments can be posted.

Demystifying UEFI, the Overdue BIOS Replacement

Comments Filter:
  • by Anrego ( 830717 ) * on Thursday September 22, 2011 @09:17AM (#37479516)

    Article was a little too light on technical details for me. This article read like something you might find in an “intro to computers” textbook. Vague somewhat-technical description of what it does and a few somewhat unclearly described differences.

    Not necessarily a bad article, just wasn't what I was hoping for :(

    • While light on some details, the article does indicate that "It sits on top of BIOS", which means you should be able to get into the BIOS to change things. It also sits either in NAND memory or a hard drive partition, (Compaq servers, anyone?) and so can be physically replaced to put Linux in as an OS instead of WinDoze8.

      Looks like all the paranoia is wasted again!
      • by tepples ( 727027 )

        the article does indicate that "It sits on top of BIOS", which means you should be able to get into the BIOS to change things.

        But will bootloader signing certificates be one of the things that the BIOS setup allows the user to change?

        It also sits either in NAND memory or a hard drive partition, (Compaq servers, anyone?) and so can be physically replaced to put Linux in as an OS instead of WinDoze8.

        Good luck convincing mainstream PC manufacturers to give up the key needed to sign your own bootloader, even if you have the "service tag" (Dell's term for a hardware serial number, as opposed to the Windows product key).

      • While light on some details, the article does indicate that "It sits on top of BIOS", which means you should be able to get into the BIOS to change things. It also sits either in NAND memory or a hard drive partition, (Compaq servers, anyone?) and so can be physically replaced to put Linux in as an OS instead of WinDoze8.

        Looks like all the paranoia is wasted again!

        The article is badly worded. It "sits on top of BIOS" on machines that HAVE a BIOS. New machines will just boot UEFI.
        If you remove UEFI you will have a brick.

        If you have a 64-bit UEFI, you will not be able to boot a 32-bit OS.

        If you have security enabled you will not be able to boot an unsigned OS.

        One goal of UEFI is so that the hardware vendors (Intel) will not have to publish detailed specs. You will only be able to access your hardware as they want.

        Looks like they sometimes are out to get the paranoids

    • by slyrat ( 1143997 )

      Article was a little too light on technical details for me. This article read like something you might find in an “intro to computers” textbook. Vague somewhat-technical description of what it does and a few somewhat unclearly described differences.

      Not necessarily a bad article, just wasn't what I was hoping for :(

      Well there is always wikipedia to the rescue: UEFI on Wiki [wikipedia.org]

  • May I ask... (Score:4, Insightful)

    by jawtheshark ( 198669 ) * <slashdot@NOsPAm.jawtheshark.com> on Thursday September 22, 2011 @09:18AM (#37479534) Homepage Journal
    What the point was of this article? There is no meat at all in there. I expected a complete deep technical overview of UEFI, not something you can summarize as "It's a little operating system providing services to the actual operating system".
    • by Anrego ( 830717 ) *

      My thought exactly.

      A good article for an intro to computers course, but I was hoping for some "how it actually works" details.

    • by tgd ( 2822 )

      The point is to get the "zomg, Microsoft is blocking Linux with Windows 8!!!" shitstorm going again, because it got everyone in a tizzy a day or two ago, and tizzies generate clicks and clicks generate ad impressions.

  • I don't know... (Score:5, Insightful)

    by AngryDeuce ( 2205124 ) on Thursday September 22, 2011 @09:22AM (#37479578)

    What is wrong with the BIOS anyway? Why does the boot process need to be all flashy? It seems like adding complexity there will just end up causing problems...

    Maybe I'm just a relic...a lot of people don't even know how to get into their BIOS anymore, let alone what the POST and such is afterwards.

    • Re:I don't know... (Score:4, Insightful)

      by betterunixthanunix ( 980855 ) on Thursday September 22, 2011 @09:27AM (#37479640)

      What is wrong with the BIOS anyway?

      It allows you to boot Linux.

      • Re:I don't know... (Score:5, Insightful)

        by AngryDeuce ( 2205124 ) on Thursday September 22, 2011 @09:33AM (#37479708)

        It allows you to boot Linux.

        The cynical, realistic part of me thinks this is the real answer.

      • Not true. You can boot Linux on systems that don't have a BIOS.

        Originally the BIOS was the full OS and on top of it sat DOS. Over the decades the BIOS just got more and more bloated. It's the only thing that takes all the various incompatible and poorly designed PC hardware and makes it look like it all just works. PCs are a mess of de-facto standards and every one is a unique design unlike all others. The BIOS is necessary to make this insane design all work. If course, the OS _could_ do this but the

    • Re:I don't know... (Score:5, Informative)

      by guruevi ( 827432 ) on Thursday September 22, 2011 @09:34AM (#37479724)

      BIOS has a LOT of limitations. >2TB hard drives, network boot, disk controllers, GPU's, IPMI, ... everything has to subvert the BIOS in some way which makes it mightily slow. My iMac boots with Lion in 7 seconds. My Linux machine takes 15 seconds just getting to Grub, my servers take up to 45 seconds to get to the boot loader.

      BIOS is ALWAYS hooked into 8086 mode (real mode) so at boot time you are limited by it's calls (such as 13h for disks) and that's hard and expensive to emulate on a non-x86 system (such as most Intel/AMD processors).

      • Re: (Score:3, Interesting)

        by walshy007 ( 906710 )

        All of the things you mentioned above are _positive_ things, in that you would have to be crazy to use the bios for anything other than loading the os and getting the hell out.

        An interesting read [kerneltrap.org] if anyone cares for it.

        All that is being done by making the boot process more complex is letting people add more bugs to firmware, do not want.

        • by tlhIngan ( 30335 )

          All of the things you mentioned above are _positive_ things, in that you would have to be crazy to use the bios for anything other than loading the os and getting the hell out.

          EFI has a driver interface that an OS can use as a last resort. So you can boot to "safe mode" and the OS, instead of using its own drivers, can use the EFI drivers and get the system in a known working state.

          Or, Linux can use it to boot on wierd hardware and at least be able to minimally use the hardware. Not a bad thing if you have

      • by geekoid ( 135745 )

        " My iMac boots with Lion in 7 seconds. My Linux machine takes 15 seconds just getting to Grub, my servers take up to 45 seconds to get to the boot loader."

        Talk abut comparing apples to orange and Three's.

        I mean, really.

        • by guruevi ( 827432 )

          How is that comparing apples and oranges? My workstation is supposed to be much faster than my iMac but the BIOS eats up all the boot time. In a server it's because several peripheral BIOS are hooking into the main BIOS and the only way to change settings is manually in the BIOS but with EFI you could re-program your cards while booted and then do a quick reboot when necessary. It just goes to show the absurdity of the BIOS and how it can be done with EFI.

      • by Twinbee ( 767046 )

        The article states that UEFI can (and will) be built on top of BIOS, so won't it inherit all the bloat and limitations of BIOS anyway?

      • That 45-second delay on servers is for storage controller initialisation... and BIOS or UEFI, it's still got to be done.
    • The main issue for me is that BIOS is just SLOW. For something that's stored in flash memory on the motherboard and is maybe a MB or two in size (if even that), it takes far too long to load up. Throw in RAID or AHCI and it doubles the boot time. BIOS is the main reason why your machine takes 30s longer to start up than it should.
      Now I'm not saying UEFI is perfect, it does seem to be a little over the top, but never the less if it allows me to have that instant-on computer that Intel has been promising us f

      • The main issue for me is that BIOS is just SLOW.

        There are limits to how fast any BIOS or BIOS replacement can proceed to reading and executing the bootloader. How long does it take to write to every page of RAM and read back from it? How long does it take for a hard drive to spin up?

        if it allows me to have that instant-on computer that Intel has been promising us for the last decade or two

        The only instant-on computers are computers with the operating system in solid-state memory. This can be an SSD. Or it can be RAM, which means the computer has been put to sleep and the hard drive spins up while the user is entering his password.

        • Soooo....you're saying that UEFI isn't any faster than BIOS?

      • The main issue for me is that BIOS is just SLOW.

        If you disable all the hardware checks and probing and don't have a bunch of add-in cards with ROMs, it takes very little time to hand off to the boot loader.

        For example, with all memory checks and the on-board SAS having RAID volumes, one of my servers takes about 4 minutes until the hand off. Disabling the hardware RAID and the boot ROM on the SAS controller (and running JBOD) saves about 30 seconds. Bypassing the memory check (24GB with NUMA is slow to check) and completely disabling the SAS controller

    • by Kjella ( 173770 )

      Well, for local boot the BIOS could just have been updated to load any X number of sectors at any 64 bit offset into memory, solving both the chainloading problems and 2TB boot disk limit. Then just let the OS do its thing and detect all the rest.

      It gets a bit more complicated if you want to say load the configuration from the network, there's netboot but with more GUI, more options, maybe verify some digital signatures and whatnot. Then your network has to be working, you maybe need some GUI screens with m

      • They could still just update BIOS. I suspect this is just a method to enforce vendor lock-in and DMCA/DRM bullshit.

        The BIOS really is an old relic the way it looks.

        Honestly, why the hell does it matter? Who cares how it looks? It gets the job done for the most part, which is what matters.

        Adding complexity to the boot process is just going to add potential for problems. Good for Geek Squad, bad for consumers.

    • Re:I don't know... (Score:5, Insightful)

      by ToasterMonkey ( 467067 ) on Thursday September 22, 2011 @11:18AM (#37481212) Homepage

      What is wrong with the BIOS anyway? Why does the boot process need to be all flashy? It seems like adding complexity there will just end up causing problems...

      Maybe I'm just a relic...a lot of people don't even know how to get into their BIOS anymore, let alone what the POST and such is afterwards.

      So... minutes of boot time spent at "press Fwhatever to enter foo" prompts is apealing to you?
      Or on the desktop side, figuring out how BIOS and one or more operating systems enumerate possible boot devices is good enough?

      For a Linux user, all the weird crap you've ever had to do in grub or lilo's configuration will get reduced to something like OS X's bless command, or an intelligent boot menu like refit at least.

      If you guys have no experience with other things like OpenBoot or don't understand BIOS limitations, you are not going to contribute much to this discussion. The article DOES describe what UEFI does and there are systems out there with better-than-BIOS firmware like Sparcs and EFI Macs already, and they have been available for yeeeeeeears. So don't poo on the article or the tech before educating yourselves.

  • From a screenshot in the ExtremeTech article: "Never run downloaded programs that are unknown to SmartScreen". So how does a software developer make a program "known to SmartScreen" for the first time other than by selling it on the Windows Store?

    From the same article:

    if you try to boot while an infected USB memory stick is plugged in, Windows 8 will warn you and refuse to load.

    So how do I tell Windows that a USB mass storage device containing an Ubuntu install image is not "an infected USB memory stick"?

    Microsoft wants you to hibernate Windows 8 rather than shut it down

    So will we finally have the ability to come out of hibernate without that one peripheral not responding?

    Reset restores Windows 8 to its base, just-like-new state. Refresh is similar, but it preserves all of your documents.

    So now "reformat and reinstall" is becoming institutionalized.

    The article links to an article about the Windows Store [extremetech.com]. It claims that "the process for getting an app certified and listed in the Windows Store will be as painless as possible." Does this include applications developed by high school students who aren't 18 yet? Or college students who don't want to spend $99 per year? It also mentions "content compliance checks", and if "content compliance checks" are anything like the ones that Microsoft uses for Xbox Live Indie Games [pineight.com], this could shut out entire genres of applications. It says "you won't be able to download a Metro app from Download.com", but wouldn't one just be able to load an app into Visual Studio Express and run it that way?

    • Some should make a soft core porn game for metro and make it very clear that it is a adult game and if it gets banned sue under 1ST amendment rights and antitrust laws.

      • by brusk ( 135896 )

        Some should make a soft core porn game for metro and make it very clear that it is a adult game and if it gets banned sue under 1ST amendment rights and antitrust laws.

        Antitrust maybe, but the First Amendment only protects you from government restrictions on speech, not from private individuals or corporations.

  • UEFI is good. (Score:4, Informative)

    by sgt scrub ( 869860 ) <saintium AT yahoo DOT com> on Thursday September 22, 2011 @09:35AM (#37479748)

    Secure boot is bad. What is mysterious about that? If you want to understand more, related to booting Linux, read these. UEFI secure booting [dreamwidth.org] x86 EFI boot stub [lwn.net]

    • by geekoid ( 135745 )

      Secure boot is good. What is mysterious about that?

    • by Bengie ( 1121981 )

      Hypothetical situation: Mom's computer gets infected with a rootkit. On the next reboot, the rootkit attempts to take over and load before key OS comments, so it can't be detected.

      What is your answer to making sure this situation can't happen?

      The OS is compromised, so you can't trust the OS. Next best thing is to trust something other than the OS. So now we require the BIOS to be the gate keeper. How does the BIOS determine if something is "trustable"?.... Sign it.

      All of this stuff is perfectly logical, unl

    • Re:UEFI is good. (Score:5, Interesting)

      by Sloppy ( 14984 ) on Thursday September 22, 2011 @11:08AM (#37481070) Homepage Journal

      Secure boot isn't necessarily a dumb idea and would be harmless, if done sensibly. The firmware just needs to present a UI where the owner can manage (add and delete) all the public keys used to check signatures for what the machine's owner authorizes it to run. If you buy a computer and then you are the arbiter of your computer does, then at worst that's an added capability that you don't elect to use, and at best it's useful.

      But yeah, I doubt any manufacturers are installing firmware that does it right. If any are, they need to speak up so that people will know their hardware is safe to buy.

  • "Re-imagining" (Score:5, Insightful)

    by L4t3r4lu5 ( 1216702 ) on Thursday September 22, 2011 @09:37AM (#37479784)
    Fuck everybody who uses that word. It belongs in the marketing buzzword incinerator with "thought-shower", "synergy", "pro-active", and anything "in the cloud".
    • Re-imagining means: "I imagine it will work this time", after it didn't work the first time you imagined it either.
  • Yes, I recognize that MS can abuse UEFI. Given that my work machines are WinXXXXX I don't have a choice about that, and I would assume that at some point there will be mobos that aren't controlled by M$.

    My question is ten times simpler: If this thing is flashable memory, etc., doesn't it open the doors to way more cracking by folks I'd really rather avoid, that is, identity thieves et. al? How is going away from silicon going to affect this?
  • by spudnic ( 32107 ) on Thursday September 22, 2011 @09:49AM (#37479932)

    YOU-fee?

    YOU-fi?

    you-EF-ee?

  • The only reason UEFI is overdue is not because they are slow in development. It's simply the fact that UEFI isn't an open standard. If UEFI was made an open standard every new computer in a month would all have UEFI.

    • The only reason UEFI is overdue is not because they are slow in development. It's simply the fact that UEFI isn't an open standard. If UEFI was made an open standard every new computer in a month would all have UEFI.

      Yep. And each implementation would be different.

    • The only reason UEFI is overdue is not because they are slow in development. It's simply the fact that UEFI isn't an open standard. If UEFI was made an open standard every new computer in a month would all have UEFI.

      Interestingly, many manufacturers are already using UEFI for quite a while. I believe most AMD64 based systems use it, even though the interface is still that of the legacy BIOS's as far as the user is concerned.

    • The only reason UEFI is overdue is not because they are slow in development. It's simply the fact that UEFI isn't an open standard. If UEFI was made an open standard every new computer in a month would all have UEFI.

      So, how come every new computer doesn't have Open Firmware [openfirmware.org]?

  • Read UEFI as UFIA. On further review, yep, that's about right.
  • Coreboot (Score:2, Insightful)

    by Anonymous Coward

    Needs a marketing department.

  • by Anonymous Coward on Thursday September 22, 2011 @10:31AM (#37480540)

    I've been dealing with UEFI-based servers for the past couple of years - IBM System x specifically - and while I see the potential for UEFI, it's still got a lot of teething pains in the Enterprise space as far as I am concerned. IBM was the first to basically put their entire x86 product line on UEFI-only hardware.

    However, I have actually encountered machine configurations that BIOS was unable to deal with (add-in PCIe cards utilizing all of the ROM memory space and bringing the machine to a halt, amount of RAM beyond what BIOS can handle natively, etc...) so I can see the requirement for a BIOS replacement.

    In its current incarnation in the servers I deal with, the architecture is essentially booting two full-blown microprocessors running code *BEFORE* the machine will even attempt to POST. The service processors in the current IBM machines (IMM - Integrated Management Module) are the first thing to fire up when power is applied to the server - since IMMs are small microprocessors in their own right (can't remember the make, but I remember hearing 100MHz speeds) loading what I believe is a micro-Linux kernel it takes time for these things to fire up. This process can take up to two (sometimes more) minutes before the power button stops blinking rapidly and goes to a normal "power off" blink. At this point you can turn the server on, which is when it will fire up the UEFI microprocessor and begin to load all of that code into the system. UEFI goes and "talks" to all of the internal hardware, loads profiles for devices, etc... during this phase. That can take up to another four minutes or so (it has gotten faster over the last two years) at which point the actual POST screen will display and you can either enter SETUP or allow the server to boot - note that add-in cards will have to load their own ROM as normal (if in Legacy Mode, which most of our server are due to OS limitations). Note that the more cards you put in a machine and more boot options you leave enabled, the longer this pre-POST initialization takes. I've seen reboot cycle times of over ten minutes in some instances, whereas the BIOS-based systems would complete that cycle in under two minutes.

    So here's a brief summary of the current state-of-the-art in server UEFI:
    PROS:
    * Allows configuration of peripheral devices from the SETUP screen.
    * Allows up to 1TB (much smaller in practive) of Option ROM space for add-in cards.
    * Allows for huge amounts of memory, and very large disk sizes.
    * In theory, allows for additional software to execute before the primary OS kicks in. Not really utilized in these machines.

    CONS:
    * Horribly slow boot cycles. Length of boot cycle dependent on amount of hardware in server. Had an IBM ATS Engineer tell me they had a machine in the lab that they plugged so much stuff into that it took 23 hours to POST.
    * Corrupt firmware or firmware updates is the kiss of death for many of these machines. While there are backup firmware spaces and the appropriate jumpers to recover, this does not always work as intended. We've had quite a few brand-new systems that had to have complete system planar replacements because the code wasn't executing right.
    * As these are actual mini-OSes running there are all kinds of strange quirks and odd behavior from the servers. Lots of troubleshooting involves resetting the service processors and praying they reboot properly in order to just get the server to POST normally.
    * Speaking of quirks, there are lots of situations where hardware failures are either false-positive failures or not indicated as an issue when they actually have faults. Troubleshooting on these machines becomes guesswork based on intuition rather than having a solid grip on what component is doing what.
    * Example: As the UEFI handles all of the components on the server, we have run into issues where bad code for the UEFI causes the Operating Systems to malfunction in strange ways, only to find the OS was reacting to thousands of repeated error messages being

    • by 0123456 ( 636235 )

      Yeah, UEFI boot time is insane. Even on my home server which doesn't have any fancy monitoring hardware the UEFI boot takes about twice as long as booting Linux once it's finished.

  • lot's of hardware raid cards have some kind of text mode GUI or a GUI that looks like the old MS-DOS Editor.

    Now it can be a big plus to have gui with mouse to config a raid card with out having to boot a full os.

  • by devent ( 1627873 ) on Thursday September 22, 2011 @10:36AM (#37480634) Homepage

    "UEFI, being a pseudo-operating system, can access all of the hardware on the computer — you can surf the internet from the UEFI interface, or backup your hard drives — and it even has a full, mouse-driven GUI"

    Why do we need that? Why we can't have a "BIOS" that just boots the bootloader or the system itself and nothing else. Maybe an option from where it should boot (from harddisk, CDROM, network, etc). Just a thing, that don't have the limitations of the old BIOS, but with the sole purpose to boot the system/bootloader as fast as possible and then just go out of the way.

    "The fact that all of this boot data is stored on NAND flash or on a hard drive means that there’s a lot more space for things like language localization, boot-time diagnostics (begone meaningless POST beeps!), utilities (backup, restore, malware scanners), and so on."

    If the graphic card or the motherboard is broken, all the computer can do is to beep, with UEFI or without. If I need diagnostics and utilities I just use my Linux live-CD or live-USB-stick (like Knoppix or SystemRescueCD). They are easy to use and much more sophisticated.

    UEFI sounds like the shiny new GUI interface that nobody will use, but it was developed because the old boring program was too old fashion. Like Nero, with was 50MB and then later became a 1GB full blown suite.

    • by devent ( 1627873 )

      "While BIOS is fundamentally a solid piece of firmware, UEFI is a programmable software interface that sits on top a computer’s hardware and firmware (and indeed UEFI can and does sit on top of BIOS). "

      The f*ck? I thought that thing is to replace the BIOS. Why they didn't just used a Linux distribution and skipped years of development time? So why do I need this UEFI again?

      • by 0123456 ( 636235 )

        So why do I need this UEFI again?

        So Microsoft can lock down your computer so it only runs code signed by Microsoft.

  • by optimism ( 2183618 ) on Thursday September 22, 2011 @10:46AM (#37480742)

    ...BIOS’s antiquated limitations were hampering systems...

    What exactly are these limitations, in real-world terms? My systems all seem to boot & run fast right now...

    If the BIOS has limitations, why not just flash an updated BIOS? All of my machines have had at least one BIOS update since manufacture. No problem.

    As for the mini-OS-before-boot concept...I already have a bunch of Linux "Live CDs" that I use to partition drives, image & restore partitions, scan for viruses, etc without having to boot Windows. Why would I want to put a "pre-boot" OS on my hard drive, where it can be hacked and infected?

    Someone please enlighten me if UEFI has any real-world benefits to outweigh its costs.

  • by billcopc ( 196330 ) <vrillco@yahoo.com> on Thursday September 22, 2011 @10:59AM (#37480946) Homepage

    Okay, I'm going to be a dick and say that UEFI is a load of crap. It has its own cute little platform-independent bytecode, which I suppose would come in real handy if you're in the business of selling motherboards that support more than one CPU architecture... wait, what ? And then manufacturers love to store a bunch of extensions on the hard drive, like in the Asus screenshot - but let's not call it an operating system okay ? Hell, Gigabyte even ships a few crappy games as EFI extensions on the motherboard CD.

    UEFI is an overdesigned solution to a non-problem. Intel has basically given everyone carte-blanche to bloat up the pre-boot experience. We already had gimmicky mouse-driven BIOSes back in the day, I remember one as far back as the 286, where AMI had replicated a Windows 2.0 style GUI. Pointless, slow, but hey it's shiny right ? :P

    What the BIOS needed was an update from its 35 year old roots - a little less 16-bit legacy cruft, a little more forward compatibility for the 64-bit era. What we got instead was a reinvention of the wheel that doesn't actually solve much. It simply replaces one simple interface with another. Instead of VESA VBE, we now use GOP, which provides (dun dun dun!) a linear frame buffer. Instead of calling interrupt 13h for disk access, we now call a C++ object. Nothing has really changed, except for the bloat.

Life in the state of nature is solitary, poor, nasty, brutish, and short. - Thomas Hobbes, Leviathan

Working...