Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Saturday November 25 2017, @02:44PM   Printer-friendly
from the bye-bi-os dept.

Submitted via IRC for Sulla

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.

Source: Intel Planning To End Legacy BIOS Support By 2020


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2) by looorg on Saturday November 25 2017, @03:24PM (5 children)

    by looorg (578) on Saturday November 25 2017, @03:24PM (#601401)

    I'll miss it like the plague. I guess I have not taught about it much for the last few years. But I used to hate having to go into the BIOS and make all the changes needed for drives and such. Then it became automated so you didn't have to bother much. Then game the "non-ascii" BIOS interfaces that looked fucking horrible and I wished I had the old BIOS again, cause at least I know where everything was back in that one. Now I don't think I checked the BIOS on any of the machines I built during the last couple of years more then once, when built just to see what was in there and if there was something I needed to change.

    That said when Intel say remove is that actual removal or is is like when Microsoft said they removed DOS and just hid it a bit in the background so the normal people couldn't find it?

    • (Score: 3, Insightful) by sigterm on Saturday November 25 2017, @03:28PM

      by sigterm (849) on Saturday November 25 2017, @03:28PM (#601405)

      >I'll miss it like the plague. I guess I have not taught about it much for the last few
      >years. But I used to hate having to go into the BIOS and make all the changes
      >needed for drives and such.

      You're talking about the BIOS setup routine, and that's not the part they'll be removing.

    • (Score: 0) by Anonymous Coward on Saturday November 25 2017, @09:22PM (3 children)

      by Anonymous Coward on Saturday November 25 2017, @09:22PM (#601502)

      Without BIOS support, it won't be possible to run DOS.

      • (Score: 0) by Anonymous Coward on Sunday November 26 2017, @05:25AM (2 children)

        by Anonymous Coward on Sunday November 26 2017, @05:25AM (#601610)

        DOSBox [dosbox.com] DOSEMU [dosemu.org]

        -- OriginalOwner_ [soylentnews.org]

        • (Score: 0) by Anonymous Coward on Sunday November 26 2017, @04:16PM (1 child)

          by Anonymous Coward on Sunday November 26 2017, @04:16PM (#601757)

          But not on the bare metal.

          The PC (as in "IBM-Compatible PC") will be dead.

          • (Score: 0) by Anonymous Coward on Sunday November 26 2017, @08:59PM

            by Anonymous Coward on Sunday November 26 2017, @08:59PM (#601828)

            Give an example where that is necessary.
            ...or even necessarily desirable.

            In a Klein flask [google.com] of logic, the only example that I can think of is flashing a legacy BIOS via a bootable disk carrying only DOS and the update routine.

            ...and there's no reason that that task couldn't be done with a minimalist Linux instance.

            .
            In the classic instance of running a legacy app in an industrial control environment, if you get your app running, what's the difference if it's a subordinate process running via an emulator?

            -- OriginalOwner_ [soylentnews.org]

  • (Score: 5, Insightful) by sigterm on Saturday November 25 2017, @03:25PM (10 children)

    by sigterm (849) on Saturday November 25 2017, @03:25PM (#601403)

    >Removing the legacy BIOS support will mitigate some security risks,

    Really? I mean, without Secure Boot, how exactly does UEFI make a system more secure? Please, name ONE recurity risk mitigated by UEFI.

    >allows for supporting more modern technologies,

    Citation needed. Given that the legacy BIOS only needs to provide services for boot devices and the keyboard, how is BIOS holding back support for "modern technologies"?

    >etc.

    Of course. We wouldn't want to miss out on all the nebulous, unquantifiable benefits of UEFI, would we?

    Ever since the original EFI specification was released, I've wondered what the benefits were. I've yet to find an answer, not even a poor one.

    The drawbacks. however, are numerous. Apart from bloating the size of the firmware by at least one order of magnitude, UEFI has in fact increased the attack surface of the system significantly: unlike with the old BIOS, we now depend on firmware services even /after/ the OS has booted. And UEFI has certainly had it's fair share of security issues; just Google "UEFI security vulnerabilities" (if you dare).

    One can even hide malware in the firmware, illustrated by the recent Lenovo fiasco. And the "universal" nature of the interface means we can now have firmware bugs that exist on equipment from multiple vendors.

    • (Score: 1, Informative) by Anonymous Coward on Saturday November 25 2017, @03:38PM

      by Anonymous Coward on Saturday November 25 2017, @03:38PM (#601406)

      I think you just explained it. "Its not a bug its a feature!!". Brought to you by The Eyes.

    • (Score: 1, Interesting) by Anonymous Coward on Saturday November 25 2017, @03:50PM (3 children)

      by Anonymous Coward on Saturday November 25 2017, @03:50PM (#601410)

      I think the better question is what security problems were there with the BIOS in the first place.

      There's plenty of reasons why we shouldn't be using the old school BIOS any longer, but security isn't really one of the ones I can think of. The BIOS was something that was cooked up when computers were less powerful and when the space available for such things was much smaller.

      If we're concerning ourselves with security, why don't we have some sort of a toggle to turn the space dedicated to the UFI into read-only when we're not actively changing things?

      • (Score: 5, Informative) by maxwell demon on Saturday November 25 2017, @04:50PM (2 children)

        by maxwell demon (1608) on Saturday November 25 2017, @04:50PM (#601426) Journal

        Well, there are three parts to the BIOS.

        Part 1 is the hardware support. That's still required, and whether it is in the form of BIOS or UEFI doesn't really matter.

        Part 2 is the service routines. Those are indeed outdated, and only used by ancient operating systems (with a few exceptions, which are used by the boot manager).

        Part 3 is the boot system. That one was a perfectly good application of the KISS principle: All the BIOS had to know for this was how to read the first sector of any drive it might boot from. Everything else was then handled by the code found there. And frankly, I don't see why more should be needed.

        --
        The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 0) by Anonymous Coward on Saturday November 25 2017, @11:14PM (1 child)

          by Anonymous Coward on Saturday November 25 2017, @11:14PM (#601537)

          Most of the stuff that UEFI can do isn't something that the BIOS couldn't have handled with an updated standard.

          The big thing that I don't think BIOS could reasonably have handled without major changes was allowing for you to run networking from a pre-boot environment. I messed around a bit with the Winki and it was OK, but the requirements for it were sufficient to make it pointless. IIRC, you had to have Windows in order for it to install and allow you to boot into it without booting up Windows.

          • (Score: 3, Informative) by sjames on Sunday November 26 2017, @12:17AM

            by sjames (2882) on Sunday November 26 2017, @12:17AM (#601546) Journal

            BIOS has supported PXE since forever. It brings up the network card, grabs an address then uses TFTP to fetch the OS kernel.

    • (Score: 4, Insightful) by Anonymous Coward on Saturday November 25 2017, @04:29PM

      by Anonymous Coward on Saturday November 25 2017, @04:29PM (#601422)

      Really? I mean, without Secure Boot, how exactly does UEFI make a system more secure? Please, name ONE recurity risk mitigated by UEFI.

      UEFI will probably be solving security problems by removing the ability to remove secure boot, thus safely securing the user from installing an operating system that the manufacturer does not approve of. This assures that the manufacturer will continue to own the hardware. Wouldn't want a pesky thing like property rights getting in the way, after all.

      By the current standard, it's already optional to be able to turn it on and off for a standard PC, anyway - and on some platforms using the UEFI standard, it's mandatory that there is no disable option in the first place.

    • (Score: 0) by Anonymous Coward on Saturday November 25 2017, @04:54PM (2 children)

      by Anonymous Coward on Saturday November 25 2017, @04:54PM (#601427)

      As far as I am concerned, EFI has exactly one benefit, complete compatibility with larger boot drives. MBRs are restricted to a maximum size of 2TB without workarounds. There are three workarounds, all with drawbacks in that software that doesn't realize they are in use. First is to use the native sector size for calculations, but not all software supports that and actually telling the difference is hard. Second is to just mark the whole thing as used, but that only works when there is one partition. Third is faking the math such that you get more than 32 bits worth of address space, but that is obviously less used.

      The solution is to use GPT but if you still use BIOS to boot through the MBR, then you still have layouts on your boot disk layout. A pure EFI boot with GPT has none of the above issues with no non-standard workarounds and protection against MBR-only tools.

      • (Score: 5, Interesting) by sigterm on Saturday November 25 2017, @05:56PM (1 child)

        by sigterm (849) on Saturday November 25 2017, @05:56PM (#601435)

        >As far as I am concerned, EFI has exactly one benefit, complete compatibility
        >with larger boot drives.

        That's actually an issue with the OS boot loader, not the BIOS.

        >MBRs are restricted to a maximum size of 2TB without workarounds.

        No, the MBR *partitioning scheme* (really the partitioning scheme used by MS-DOS) is limited to 2^32 sectors, but that has nothing to do with the BIOS. You don't have to use that partitioning scheme if you don't want to. The BIOS only needs to find a boot loader at sector 0 (the Master Boot Record) of the boot drive, and that's fully compatible with the GPT.

        Now, Windows does refuse to boot from a GPT drive unless loaded by UEFI services, but that's a limitation of the Windows boot loader. The two most common boot loaders used by Linux, GRUB and LILO, will happily boot from a GPT-partitioned drive. No workarounds required.

        If Microsoft wanted to, they could have a BIOS-compatible GPT bootloader available by tomorrow. But that's probably not going to happen, as they're somewhat invested in Secure Boot.

        • (Score: 0) by Anonymous Coward on Saturday November 25 2017, @06:19PM

          by Anonymous Coward on Saturday November 25 2017, @06:19PM (#601444)

          Somebody should take the NT4 leak, or the OpenNT fork (if you can still find a copy online) and add GPT support to it.

          Hell with a bit of knowledge of the code and some injection work one could probably support GPT on Windows XP and the Windows 6.0+ revisions as well, although you would probably need to disable driver/system file signing to get it to work.

          There is literally no reason we can't have GPT bootable M$ OSes on traditional bioses except for microsoft's intentional deprecation, and no reason we can't have traditional bioses providing advanced boot services to GPT partitions so long as there is sufficient flash space for option rom boot service code.

    • (Score: 3, Informative) by RamiK on Sunday November 26 2017, @12:32AM

      by RamiK (1813) on Sunday November 26 2017, @12:32AM (#601548)

      Really? I mean, without Secure Boot, how exactly does UEFI make a system more secure? Please, name ONE recurity risk mitigated by UEFI.

      The 16bit real execution mode lacks virtual memory and paging so all bios modules - which are closed source blobs written by chip manufacturers like Marvell RAID or Realtek LAN and TCP stack - have full access to everything.

      Citation needed. Given that the legacy BIOS only needs to provide services for boot devices and the keyboard, how is BIOS holding back support for "modern technologies"?

      Boot devices is PXE as well. And those are being held back to limited LAN application since doing network authentication in real mode without enough RAM and cryptography instructions is crazy. It will also be nice to have something like uboot's web failsafe where holding a button while powering up the PC will put you in some kind of (web-facing?) recovery mode.

      Ever since the original EFI specification was released, I've wondered what the benefits were. I've yet to find an answer, not even a poor one.

      I like updating UEFI modules well after my warranty expired and my motherboard manufacturer stopped issuing new firmwares using UBU. The odd ME update using FWUpdate also helps when me_cleaner isn't an option.

      More conventionally, between EFI boot partition, the EFI shell (and the bcfg command) and efibootmgr, most of my dual boot woes were sorted out. Windows no longer overwrites linux in ways that leave me needing to find linux boot media. Grub no longer fails to identify windows or another linux partition. Now, if the mobo oem screwed up or something isn't working right, I can always deploy rEFInd as \EFI\boot\bootx64.efi or just log-in the efi shell and chain into whatever .efi I need.

      The drawbacks. however, are numerous. Apart from bloating the size of the firmware by at least one order of magnitude, UEFI has in fact increased the attack surface of the system significantly: unlike with the old BIOS, we now depend on firmware services even /after/ the OS has booted. And UEFI has certainly had it's fair share of security issues; just Google "UEFI security vulnerabilities" (if you dare).

      ACPI predates UEFI so these issues are all x86 PC issues. So seeing how you're going to end up with some bloated piece of shit for ACPI and the dozen or so "built-in" boot features and methods early on anyhow, you might as well have a GUID based FS with some conventions to avoid breakage as different OSs and drivers mark their territory all over your NVRAM.

      One can even hide malware in the firmware, illustrated by the recent Lenovo fiasco. And the "universal" nature of the interface means we can now have firmware bugs that exist on equipment from multiple vendors.

      All also true for BIOSes as well. Just in a less obscure way.

      Overall, the removal of legacy BIOS stuff from UEFI is welcomed. Hopefully they'll have the good sense to do away with ACPI next. Regardless, I won't be missing BIOS in the least.

      --
      compiling...
  • (Score: 0) by Anonymous Coward on Saturday November 25 2017, @03:25PM

    by Anonymous Coward on Saturday November 25 2017, @03:25PM (#601404)

    Is it even possible to completely remove support for the legacy BIOS? Couldn't a board vendor install some little bit of hardware and/or ROM that implemented the BIOS and then bootstrapped the main CPU...and hung around to provide BIOS services as required.

    There are many, many expensive devices (medical, machine tools, etc) that run older software, but may need to have that software ported over to new hardware.

  • (Score: 2, Insightful) by Anonymous Coward on Saturday November 25 2017, @04:48PM

    by Anonymous Coward on Saturday November 25 2017, @04:48PM (#601425)

    i better be able to use my own keys without some third party being involved or you're going to have hell to pay.

  • (Score: 2) by deimios on Saturday November 25 2017, @06:09PM (1 child)

    by deimios (201) Subscriber Badge on Saturday November 25 2017, @06:09PM (#601440) Journal

    Right now if you refuse to pay the microsoft tax most newly bought PC-s are loaded with FreeDOS or a small minority wih a linux distro. FreeDOS has no UEFI support so that won't work forever. I wonder what PC builders will use on these systems.
     

    • (Score: 4, Interesting) by pTamok on Saturday November 25 2017, @08:19PM

      by pTamok (3042) on Saturday November 25 2017, @08:19PM (#601487)

      They could use Ubuntu with the SecureBoot shim - the root is still signed by Microsoft

      Ubuntu SecureBoot [ubuntu.com]

      The issue is, of course, that you no longer have the illusion of control of your hardware.

      Why do I say the 'illusion of control' - well, even now, because Intel's and AMD's hardware is closed, you do not know what backdoors may already have been implemented, or what vulnerabilities may have been kept hidden. The panic-du-jour is about Intel's management Engine (ME), and, to a lesser extent, AMD's PSP; but in the absence of verified open hardware and software, you simply have to trust the vendors. If you are not a nation-state, this is probably not a big issue, but for people who like to make unauthorised copies of copyrighted works (like music and movies) it makes life a little more difficult.
      It is not a coincidence that both China and Russia are looking at designing and building their own processors and system architectures. If there is hope, it is if somewhere like Brazil or Japan decide to produce open hardware and open systems, and make them available to everybody. In my most cynical moments, I wouldn't be surprised if Trade Treaties like the TPP contain clauses to prevent specifically that.

  • (Score: 0) by Anonymous Coward on Saturday November 25 2017, @06:10PM

    by Anonymous Coward on Saturday November 25 2017, @06:10PM (#601441)

    ME is outside of main CPU. It controls the damn machine. Make it do the full job. BIOS or EFI does not matter then. You can run a BIOSbased machine right next to WINDOWS XII. No skin off anyone nose. Hell,they could offer a BIOS add on module to offer boot of old systems.

  • (Score: 5, Interesting) by jmorris on Saturday November 25 2017, @07:16PM

    by jmorris (4844) on Saturday November 25 2017, @07:16PM (#601463)

    All that needs to happen is somebody cook up a BIOS compatibility layer as an EFI executable and GPL it. It could even support a classic looking BIOS Setup screen to configure it where the variables get stored in the UEFI space. Since TianoCore includes a CSM it should not be a big effort to pull it out as a standalone piece distributed as a bootable image with an installer. If MBR support is eliminated entirely it would mean you would need a small boot volume to hold the EFI partition.

    A wee USB stick should suffice, get an image signed and distribute it ready to toss onto a stick. Pop it in the back of the machine, configure it to boot and UEFI basically goes away, even against secure boot. At least until Microsoft demands the UEFI keys be omitted and only the Windows keys installed. Which is of course where this is supposed to end, with the PC platform as locked down as iOS, Android and Windows tablets. For our protection.

  • (Score: 3, Informative) by Anonymous Coward on Saturday November 25 2017, @07:43PM

    by Anonymous Coward on Saturday November 25 2017, @07:43PM (#601473)

    No, not really. Its just one more step in making our machines, 'theirs.

  • (Score: 2) by SomeGuy on Saturday November 25 2017, @09:25PM

    by SomeGuy (5632) on Saturday November 25 2017, @09:25PM (#601504)

    While we are at it, we should just get rid of all firmware. :P

    There were actually some CP/M-80 era machines that could boot just fine without a single ROM or line of firmware bootstrap code. At powerup the disk controller would hold the CPU in a reset state, perform a hardware DMA operation to load the boot sector from the floppy, then release the CPU and run the code. The upshot was an 8-bit system could have a full 64k of RAM without any kind of paging.

    Once BIOS support is gone, the computers people will be selling will in no way, shape, or form, be "IBM PC" compatible, or worthy of the term "PC".

    On a side note, would there still be enough hardware support left for a software tool like Apple's Boot Camp to work? I don't know that anyone has tried such a thing on a PC yet since they have retained BIOS compatiblity.

    Also, if this is just Intel then what is AMD doing? Fuck you, Intel.

  • (Score: 1, Insightful) by Anonymous Coward on Sunday November 26 2017, @01:08AM

    by Anonymous Coward on Sunday November 26 2017, @01:08AM (#601550)

    As long as we only have limited choices for hardware, you will continue to be pulled around by the nose by Intel, AMD, etc. Until serious investment into open source hardware occurs, this will continue to be the norm.

  • (Score: 2) by darkfeline on Tuesday November 28 2017, @08:40AM

    by darkfeline (1030) on Tuesday November 28 2017, @08:40AM (#602418) Homepage
    I found an informative article [happyassassin.net] explaining UEFI and Secure Boot in laymen's terms, for those of you who fancy yourselves more intelligent than parrots repeating FUD.
    --
    Join the SDF Public Access UNIX System today!
(1)