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.
  • (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...
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3