Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Intel Technology

Intel Planning To End Legacy BIOS Support By 2020, Report Says (phoronix.com) 122

Posted by msmash from the up-next dept.
Michael Larabel, writing for Phoronix: Intel is planning to end "legacy BIOS" support in their new platforms by 2020 in requiring UEFI Class 3 or higher. Making rounds this weekend is a slide deck from the recent UEFI Plugfest. Brian Richardson of Intel talked about the "last mile" barriers to removing legacy BIOS support from systems. By 2020, they will be supporting no less than UEFI Class 3, which means only UEFI support and no more legacy BIOS or CSM compatibility support mode. But that's not going to force on UEFI Secure Boot unconditionally: Secure Boot enabled is considered UEFI Class 3+. Intel hasn't removed legacy BIOS / CSM support yet due to many customers' software packages still relying upon legacy BIOS, among other reasons. Removing the legacy BIOS support will mitigate some security risks, needs less validation by vendors, allows for supporting more modern technologies, etc.
This discussion has been archived. No new comments can be posted.

Intel Planning To End Legacy BIOS Support By 2020, Report Says More

Intel Planning To End Legacy BIOS Support By 2020, Report Says

Comments Filter:

  • Coreboot (Score:1)

    by Anonymous Coward

    Hopefully Coreboot will be more widespread by then and UEFI can just be a compatibility layer on top of Coreboot.

    • Re: (Score:1)

      by jazzis ( 612421 )

      Hopefully Coreboot will be more widespread by then and UEFI can just be a compatibility layer on top of Coreboot.

      FYI: https://eshop.macsales.com/gui... [macsales.com] Plue Safari /Security, URFI and major Apps back to Lion (10.7.x) 64 bit

  • Force secure boot on unconditionally? (Score:5, Insightful)

    by ReluctantRefactorer ( 223101 ) on Monday November 20, 2017 @09:11AM (#55586515)

    As long as the user can always install their own platform key, so they retain ultimate control of their own computer, then this isn't such a big deal. But there needs to be a standardised interface for installing platform keys in the UEFI settings.

    • That's not even required in EFI Class 3, per the article:

      that's not going to force on UEFI Secure Boot unconditionally: Secure Boot enabled is considered UEFI Class 3+.

    • Re:Force secure boot on unconditionally? (Score:5, Insightful)

      by Junta ( 36770 ) on Monday November 20, 2017 @09:27AM (#55586619)

      Well, one, SecureBoot is not mandated. Been UEFI booting since before SecureBoot existed.

      Two, *if* it were mandated, using UEFI settings menu interactively isn't going to cut it, as large deployments need less manual attention. Some automation friendly mechanism is needed. The challenge being that it's hard to make an automation friendly capability that isn't also malware friendly.

      I would have liked the mechanism to ship unlocked until an OS vendor installs, which would then have optionally locked the platform to that vendors or enduser keys. But instead we get the joy of Microsoft's keys being the arbiter of the whole SecureBoot platform.

      • Re:Force secure boot on unconditionally? (Score:5, Insightful)

        by ( 4475953 ) on Monday November 20, 2017 @10:26AM (#55587031)

        Looks like a false dichotomy to me. Why can't they make chipsets/motherboards that allow me to change UEFI settings (incl. installing my own keys for secure boot or switching it off) and switch off/on Intel ME by flipping physical switches, while at the same time offering chipsets/motherboards with less secure, but corporate-friendly automated mechanisms?

        My guess is that they don't want to allow the first option because someone asked them not to allow it. In fact, I have no other explanation. Adding two jumpers and adjusting the firmware in an appropriate way doesn't seem like a major price point or technical obstacle that Intel just can't afford or solve.

        • Re:Force secure boot on unconditionally? (Score:4, Funny)

          by omnichad ( 1198475 ) on Monday November 20, 2017 @11:44AM (#55587647) Homepage

          installing my own keys.....by flipping physical switches

          You want to have 2048 dip switches for entering your secure boot key? I'd rather use a GUI for that.

          • How about designing it to read a boot ROM, including install keys, off of a micro-SD card?
        • If you want to use SecureBoot and the TPM to provide a chain of trust then you don't want an attacker to be able to flip a DIP switch and disable it. The kind of customers that really want this sort of thing are people who want to stick a load of machines in a data centre that's managed by someone else and be sure that no one on site can tamper with them without being detected.

          • Re: (Score:2)

            by skids ( 119237 )

            There's a solution to that: When the DIP switch is flipped, everything gets completely erased before any access to the key-loading utility is allowed. It's already done that way on some brands of ethernet switches... you can always bring the switch back to baseline if you forgot the password, but if you set it up in this certain mode, doing so erases all your keys and configuration (though I doubt it is actually very secure to a JTAG case intruder).

            So, that reduces the problem to: someone who can flip a d

          • Re: (Score:2)

            by Junta ( 36770 )

            Well SecureBoot and TPM don't really relate.

            SecureBoot merely validates that the OS booting is 'a' legitimate OS (for some value of legitimate). For the most part it means 'microsoft thinks this isn't malware'.

            TPM gets into more specifics, and even it explicitly has the concept of physical presence as a way to 'recover' things.

            However, a best practice there is for you to have an encrypted volume, with the keys sealed to TPM PCRs. Any TPM 'recovery' will make that sealed copy forever unrecoverable. So som

      • I would have liked the mechanism to ship unlocked until an OS vendor installs, which would then have optionally locked the platform to that vendors or enduser keys. But instead we get the joy of Microsoft's keys being the arbiter of the whole SecureBoot platform.

        The latter is the result of implementing the former in a world where every computer is sold with a Microsoft OS. You got what you want, it just wasn't thought through.

        • Re: (Score:2)

          by Junta ( 36770 )

          In consumer market, true, and there the mandatory 'replace key using firmware config menu' is passable.

          In business market, it is exceedingly common to ship computers without OS image and the business receiving is responsible for OS load choice, which is where scalable automation is critical.

          • Indeed, and in that market it is even more common to find Windows, hence it makes sense that the Windows key is preloaded.

    • Re: (Score:2, Insightful)

      by Rockoon ( 1252108 )
      a standard interface probably means it can be hacked by malware - careful what you wish for

      • Re: (Score:2)

        by mark-t ( 151149 )

        That's fine... the OS can be written to disallow an arbitrary user from being able to access the interface via software. Root or admin user should still be able freely use the API as it is designed.

        If an otherwise unauthorized person somehow gets root/admin privileges, then... well... you were boned already.

    • But there needs to be a standardised interface for installing platform keys in the UEFI settings.

      There already is. If your board supports it, and if secure boot is in setup mode, then efi-updatevar can write UEFI secure boot keys. (Mine doesn't, I have to use the UEFI menu to replace keys.)

      The process of enabling secure boot for self-signed kernels is not for the faint of heart but it can be done. [gentoo.org]

  • From the motherboard (Score:3)

    by omnichad ( 1198475 ) on Monday November 20, 2017 @09:13AM (#55586531) Homepage

    I doubt this would prevent someone from running a BIOS emulation layer through an EFI boot loader, just removing it from the EFI firmware. Can anyone confirm?

    • Re: (Score:2)

      by Junta ( 36770 )

      Note that usually BIOS boot is a BIOS emulation layer ('CSM') hosted in the firmware.

      The usual approach has been that Intel reference platform included that emulation. Moving forward, they plan not to, however system vendors may opt to include it of their own volition.

      Of course, in order to suspend UEFI runtime services, the UEFI would have to cooperate, so emulating BIOS without the cooperation of the firmware platform would be pointless, since you have the relatively small downsides of UEFI without the u

    • Re: From the motherboard (Score:1)

      by Anonymous Coward

      Hell, Intel could do this today with their MIMIX in the north bridge. Whole system boots clean and secure. BIOS comparability is an add on module to MINIX. Hell, they can (and do) be a hyper visor. So Linux and windows and the rest of the OSes can run side by side out the door.

  • As one who works at a vendor.... (Score:5, Interesting)

    by Anonymous Coward on Monday November 20, 2017 @09:13AM (#55586533)

    Intel has set deadlines for the death of BIOS and they came and passed and there was still BIOS.

    This time they seem a bit more serious about it, but the UEFI vendors are planning to continue allowing CSM so long as they have customers.

    Intel NICs may stop providing BIOS boot roms, new Intel storage devices may be only UEFI bootable. It will get harder and harder and more and more cases will require UEFI boot.

    UEFI boot has gotten pretty normalized, it's a bit weird to formalize vfat as a required portion of the standard, but it is better than the MBR approach. UEFI runtime services are not as good as they should have been, but they do however take some memory away from the OS that BIOS and BIOS style boot of UEFI did not have to reserve.

    • Re:As one who works at a vendor.... (Score:5, Informative)

      by wierd_w ( 1375923 ) on Monday November 20, 2017 @09:46AM (#55586743)

      Low memory is also significantly less important on a UEFI system, because it boots straight into protected mode. Eventually, Intel will completely do away with trappings like v86 mode and pals, because they wont really be needed or useful, and will just be gobbling up die space.

      What complicates intel's master plan, is that DOS (especially since the freedos project is very mature and has no licensing fees) is a very approachable target for many applications even in the modern era (Many things, from airport metal detectors to vinyl cutters, to industrial robots and pals), and that requires BIOS to operate. That you do not need to lug around a huge OS stack (DOS lives comfortably in less than 1mb of RAM), and dont have to contend with hundreds of multitasking processes (So your single task-oriented solution does not end up competing for resources or hardware events, because it is operating at realtime instead of time slices or having to wait for spin locks to disengage, etc) makes DOS a very approachable platform even today.

      Intel just does not like that. It sees UEFI and their management processor security device model being the future in modern computing, and much like AMD, probably will only give up the keys to the management engine's castle after the vandals storm the place. (Meaning CoreBoot and pals will have to find ways to smash down the custom minix's doors and take over by force to overcome the designed security features of the processor, and hand them over to proper user control.) This is because the premise of the technology defacto asserts that the end user is not capable of being trusted with the security of the platform, and that only trusted persons or entities (orgs) can be vested with that responsibility. (This is at odds with GNU's philosophy.) Intel has many deep-pocketed orgs demanding this level of digital lordship, (microsoft *AND* apple being among the big ones), so the money is in giving the big pocketed groups what they want, which is mutually exclusive to projects like coreboot.

      • Eventually, Intel will completely do away with trappings like v86 mode and pals, because they wont really be needed or useful, and will just be gobbling up die space.

        I'd be very surprised if they weren't entirely microcode today. Who cares if every real mode instruction takes 10 cycles to complete - no customers large enough to care about have performance critical real-mode code, and the few that do are probably happy if it's a few thousand times faster than their 80286. If it's in microcode, it's taking a trivial amount of die space and none in performance-critical parts.

    • Re: (Score:2)

      by swb ( 14022 )

      Isn't the bigger question "When will virtualization vendors stop supporting it?"

      It almost doesn't matter as long as the major virtualization platforms continue to support BIOS boot. Supporting older software on new hardware has long been a strength of virtualization.

  • As expected... (Score:3, Insightful)

    by Anonymous Coward on Monday November 20, 2017 @09:20AM (#55586561)

    Deliberately limiting customer choice and putting the machine that much closer to just being outright owned by the manufacturer, no matter who paid for it.

    And as per usual, it's in the name of "security." The current UEFI standard means that the manufacturer doesn't have to let you add boot signature keys to the firmware, either. While there will be machines that can bypass this "upgrade," they'll be sure to slowly be priced sky high.

    Let's see how long it takes Microsoft to try to cram Windows 10 S down all our throats and choke out any programs they can't control, and pay off the manufactures not to include facilities to add keys by end users except for an ever-increasingly expensive high end. After that, who knows what they'll try to force you into? They've already been talking about forbidding users from accessing websites they don't like. Or the "anti-cheating" features they're adding? You'll be able to turn them off... just like you could turn off UEFI secure boot, in the beginning.

  • so I Have to reflash my SAS cards to uefi mode? why do I really need a full GUI for a server that's only vga out is used for the impi card?

  • Completely Untrue (Score:4, Insightful)

    by Anonymous Coward on Monday November 20, 2017 @09:24AM (#55586599)

    'Removing the legacy BIOS support will mitigate some security risks, needs less validation by vendors, allows for supporting more modern technologies,

    Don't twist the wording - tell the truth.

    Last time I looked I have NEVER seen a bios attack, excluding published NSA exploits.
    The correct wording would be obsoleting older devices and pathways that support unconditional video decoding, and preventing other means to turn off underhanded telemetry and back door audits.

    UEFI has plenty of proven security risks including a back door management interface that cannot be turned off. UEFI is flawed by design, and is pandering to Hollywood generally.

    The sad thing is that Raspberry Pi or similar will soon be capable of 4K video processing, as are some streaming boxes now, so Hollywood has already lost out to sub $80 boxes.

    • Re:Completely Untrue (Score:5, Informative)

      by thegarbz ( 1787294 ) on Monday November 20, 2017 @12:17PM (#55587993)

      Last time I looked I have NEVER seen a bios attack

      Found a millennial. Those of us with a few more grey hairs on our beards remember BIOS modifying related malware basically showing up as one of the originals during the birth of PC malware.

      That's to say nothing of the fact you've had your eyes closed to multiple cases over the past few years, to say nothing of the several that have been discussed on Slashdot in the past.

      • Last time I looked I have NEVER seen a bios attack

        Found a millennial.

        Hardly a discerning statement for millennials. A BIOS that has a physical switch to prevent reflashing is difficult to attack, put not impossible. Non-volatile memory used for configuration is a potential vector, but would likely need to be specific to BIOS vendor and version. In the case that a physical control is not present, or just left on, malware could, after gaining a privilege execution level attempt to replace or patch the BIOS.

    • UEFI is flawed by design, and is pandering to Hollywood generally.

      Give it a few days. Someone will step forward and #metoo accuse UEFI of sexually harassing them, then UEFI will be axed.

  • ok now force Vendor to give you impi bios updates with out needing to buy an addon key to unlock that.

  • Does this mean that from now on, just like apps on a mac, everything we run during boot time has to be signed by a corporate?

  • Mere Mortal question (Score:4, Interesting)

    by McLae ( 606725 ) on Monday November 20, 2017 @09:35AM (#55586653) Homepage
    OK, so what does this mean for me? Too much jargon to decipher. And this is new systems, right?

    References?

    • The short version is that now all your new computers will be capable of contracting viruses that you can't get rid of just by reformatting all drives and reinstalling your OS.

  • Will Google end Intel support? (Score:2, Funny)

    by Anonymous Coward

    Replace Your Exploit-Ridden Firmware with Linux [youtube.com]

    Google has already been thinking about switching to POWER chips [fool.com]. Maybe this UEFI thing will be the final push they need?

  • Does this mean x86 no longer has to support 16 bit mode? My understanding is that with EFI, the processor never enters real mode, and initializes directly in protected mode.

    • Re: (Score:2)

      by Dwedit ( 232252 )

      Even Windows 10 32-bit edition will still run 16-bit Windows 3.1 Applications. So as long as people install the 32-bit edition of Windows 10, the processor will need to have 16-bit support.

      • I thought those ran on a virtual machine. Even if NT4, if I remember right, DOS/16 bit apps did not have direct hardware access and ran in some sort of virtual machine enviornmnet.

        • It runs the same instructions directly on the CPU, but Windows implements the DOS system interrupts differently.

          If it was a virtual machine environment, then 16-bit apps would work on 64-bit Windows. They don't.

          • It IS a virtual machine. It's a virtual 8086. But that doesn't work in the long mode, which is why there's no 16-bit mode anymore on 64-bit Windows. That functionality depended on hardware support, so when the hardware support disappeared, so did this Windows feature.

    • Re: (Score:1)

      by Anonymous Coward

      As per the Intel 64 and IA-32 Architectures Software Developer's Manual [intel.com] on page 8-20 in Volume 3A, the boot processor comes up in real mode and begins executing whatever is in memory at 0xFFFF_FFF0h. On step 8 out of 15 it switches the processor into protected mode.

    • My understanding is that with EFI, the processor never enters real mode, and initializes directly in protected mode.

      All current x86/x64 chips start in real mode. So EFI has to make a switch to protected mode with long mode enabled.

      However Intel has sold chips which boot up in protected mode in the past. E.g.

      https://en.wikipedia.org/wiki/... [wikipedia.org]

      The Intel 80376, introduced January 16, 1989, was a variant of the Intel 80386SX intended for embedded systems. It differed from the 80386 in not supporting real mode (the processor booted directly into protected mode) and having no support for paging in the MMU. The 376 was available at 16 or 20 MHz.

      Of course so long as the PC standard includes the Bios, such a chip can't be PC compatible. Actually the 376 is a perhaps a bad example because it didn't have an MMU. However suppose you had a legacy free x64 chip which booted up in long mode and didn't support real mode. Such a devic

  • UEFI isn't that secure anyway. It isn't that hard to break. Personally I think the only reasons for putting it in place was to give Linux a hard time (make i hard for people to move to Linux, thank you M$) while at the same time to give a false sense of security. Given that Intel (and AMD in some processors) have an OS on the CPU that can effective be a full privileged back door, I wouldn't be surprised if UEFI had elements of the same:

    https://threatpost.com/cert-wa... [threatpost.com]

    It would be nice if computer har

  • Why does it matter? (Score:5, Insightful)

    by thogard ( 43403 ) on Monday November 20, 2017 @11:21AM (#55587491) Homepage

    BIOS and EFI should only hand the boot loader an bit of RAM and boot image and enough extra stuff to load anther few megabytes off the boot source. I don't care if you call the BIOS something else like UEFI . Everything else should be up to the boot loader and the OS. I don't need the BIOS (or its successors) to test all the memory, just the 1st gig or so. If it is booting off disk, I don't need it to know about the network. I don't need it to know about the video or even the keyboard unless there is a problem. I only need it to know about NVE if I'm booting off that. The OS should rescan all the hardware and ignore anything provided by the BIOS.

    Excessively complicated BIOS is a security risk not matter what it is called.

    • Better yet, divorce the boot source and "BIOS" firmware -- load most firmware into a special area of RAM (or dedicated RAM) from a specially-formatted micro-SD card. Removable ROM would also remove any possible issues with "bricking" a system due to a bad update.

    • I would care if I still ran DOS, or a Windows booted from DOS. Otherwise, there's just no reason to give a damn.

  • Coinciding with the Windows 7 EOL (Score:1)

    by Anonymous Coward

    This will stop 7 users which already don't get supported updates anymore. This will continue 10's spyware regime with the alternatives being $ystemD infected Linux, obscure BSDs or having to go to Macs or Chromebooks, which won't have the games and business apps. Otherwise people will have to use old hardware which will go up in price.

    Captcha: hooked.

  • Once again we're left at the mercy of a multinational corporation who doesn't give a shit about anything except maximizing profits. Intel and google like to peddle their vendor lock-in as security features. They're so dishonest, but that's good. Every so often you have to remind yourself that despite the nice talk, they're not your friend. Just pretending.
  • https://firmware.intel.com/sit... [intel.com] OS X /macOS has been IFI /UEFI for Decades so if you need a UNIX for Intel UEFI.... Look no futher/
    • Problem is that MacOS is increasingly locked down (hiding the disable for Gatekeeper) and hobbled by Apple. It's also tied to Apple hardware. Some of us want to run a really free OS, not the watered-down thing that OS X has become.

  • Pure 64? Ever? (Score:3)

    by Zo0ok ( 209803 ) on Monday November 20, 2017 @03:18PM (#55589685) Homepage

    How about dropping everything except 64 bit mode. Boot straight to 64 bit, no turning back, no legacy, no compability?
    How many CPUs actually ever run anything than 64 bit today?
    (I do understand many windows desktops do, but apart from that: servers, linux computers, chromebooks should never need anything less than 64 bit mode)

  • The real problem is not UEFI but Intel's ME.

Slashdot Top Deals

Serving coffee on aircraft causes turbulence.

Close