Intel to Remove Legacy BIOS Support from UEFI by 2020
by Anton Shilov on November 22, 2017 1:30 PM EST- Posted in
- Motherboards
- Intel
- UEFI
- BIOS
The PC Basic Input/Output System (BIOS) will turn 39 in three years, and as it turns out, this is when it is going to die on 64-bit Intel platforms. In recent years, Intel has implemented its Unified Extensible Firmware Interface (UEFI) mechanism with legacy BIOS support as an additional option, however the company intends to remove legacy BIOS support from its UEFI by 2020 in an effort to improve security. For most users, the removal will go unnoticed, but for those who use and rely on legacy hardware on the newest platforms, it means migrating to other platforms.
BIOS functionality has evolved over the years, but its key purposes remained intact - run the POST (power-on self-test) to identify and initialize key system components (CPU, RAM, GPU, storage, DMA controllers, etc.), lead to OS boot and then provide certain I/O functions for older operating systems. Standard PC BIOSes from the early 1980s had numerous limitations (a 16-bit processor mode, 1 MB of addressable memory space), which needed to be hacked around starting in the late 1980s, but by the 2000s the industry started to move on to a new iteration: UEFI. UEFI was designed to not have decades-old constraints and is considerably more sophisticated in general.
In order to guarantee a smooth transition from BIOS to UEFI (by ensuring compatibility with legacy software and hardware that uses 16-bit OpROM), the Unified EFI Forum (which consists of virtually all the important developers/suppliers of hardware) defined several UEFI system classes and introduced an optional Compatibility Support Module (CSM) to UEFI class 2 to help smooth the process.
The vast majority of PCs today feature UEFI class 2 and thus can expose either UEFI or BIOS interfaces, which can be selected in the BIOS configuration. There are systems that belong to UEFI class 3/3+ already (e.g., Microsoft Surface Book), but they are rare. In a bid to make capabilities like UEFI Secure Boot ubiquitous, Intel plans to remove CSM support from new client and server platforms by 2020. As a result, all new platforms from that point on will be strictly UEFI class 3.
Once CSM is removed, the new platforms will be unable to run 32-bit operating systems, unable to use related software (at least natively), and unable to use older hardware, such as RAID HBAs (and therefore older hard drives that are connected to those HBAs), network cards, and even graphics cards that lack UEFI-compatible vBIOS (launched before 2012 – 2013). Those who need older programs will still be able to run them in virtualization mode, but outdated hardware will have to be retired or remain on older platforms.
For the remaining years, Intel recommends to its partners to improve the UEFI user experience, promote UEFI features like secure boot, signed capsule and other, and remove DOS/BIOS dependencies from production maintenance tools. Essentially do everything to lower significance of CSM.
An interesting question regarding depreciation of legacy BIOS support on Intel’s new platforms is which of them will be the first to drop CSM in the client space. Intel is preparing a number of client platforms for mainstream desktop and mobile PCs (Cannon Lake, Ice Lake) to be released in the coming years, but at present we have no idea whether the company intends to trim CSM to a point in 2020, or if it will be a hard change over.
It remains to be seen whether AMD has similar plans - we have reached out to determine the state of play. The main reason Intel is performing this change is due to security, and certain OEMs may require specific UEFI features in their future products.
Update 11/23: *The original BIOS was invented by Gary Kildall of Digital Research for computers based on Intel 8080/85 processors and CP/M operating system in circa 1975. Then, IBM incorporated BIOS into its IBM PC based on the Intel 8088 in 1981. Since for many the history of personal computers starts from IBM PC, the history of BIOS starts from 1981 as well. In this case, BIOS is 36 years old today.
Related Reading
- The AnandTech Coffee Lake Review: Initial Numbers on the Core i7-8700K and Core i5-8400
- The AMD Zen and Ryzen 7 Review: A Deep Dive on 1800X, 1700X and 1700
- Samsung Laptop UEFI Bugs: Not Just for Linux
- Intel Officially Reveals Post-8th Generation Core Architecture Code Name: Ice Lake, Built on 10nm+
Source: Intel/Unified EFI Forum
Facebook
Twitter
RSS
22 Comments
View All Comments
wumpus - Wednesday, November 22, 2017 - link
Does this mean anything for the end user? Does it mean anything for embedded?I suspect that there might be the occasional use of DOS for certain embedded jobs that really don't want anything grabbing the CPU, but what you need x86 for but not a real RTOS is pretty small (and fancy processors already have serious latency issues, stick to the classics and "made for embedded" processors if you want to count cycles).
I'm guessing we will miss the joy of this https://www.youtube.com/watch?v=bS9hiSwL1KY
(lazy game reviews installs DOS on a 2017 game machine) and not much else.
HStewart - Wednesday, November 22, 2017 - link
Most uses of older operating systems would use virtual cpu environment like VMWare or DOSBox.For embedded, the first thought I would think in such environment you would need to virtualize the bios - this can be done by using power of 386 at the time cpu - to load the bios code into memory space. I did this with Video Bios at my first back in late 80's early 90's. You likely also have to virtualize the IO Ports.
I would think now a days - most embedded environments don't depend on the bios.
When I did development with PC-MOS back in late 80's and early 90's we pretty much emulated all the bios and in fact DOS interrupt functions at the time.
baka_toroi - Wednesday, November 22, 2017 - link
So this is basically a way to make Secure Boot a mandatory feature down the line. Prove me wrong.By 2032 only "terrorists" will use open computing.
ddriver - Wednesday, November 22, 2017 - link
And possession of a general purpose computer device will be punishable by death.CaedenV - Wednesday, November 22, 2017 - link
well, terrorists and businesses loljust this last week I had to reinstall win10 on a PC because Dell's pre-boxed version of win10 would not take our antivirus. Disable secure boot, boot from flash, a 7 min install process (win10 installs soooooo fast!), and we were back in business.
Keep in mind that secureboot does not mean that you can't reinstall an OS, or install another one. It just means that you have to have physical access to the device, and appropriate media to boot from. It is really only there to keep the kids from installing linux on their parent's work laptop lol
Also, far more secure against USB based attacks, and other firmware/middleware vulnerabilities. Throw a password on your UEFI and apply some disk encryption and you have a fairly secure box that people cant get data off of without lots of effort... or an Intel IME vulnerability X-P
wolrah - Wednesday, November 22, 2017 - link
I don't think you understand how secure boot works.You can netboot with it, you can install Linux with it, etc. All it cares about is that the code you're loading has a signature that validates with one of the keys stored on the system.
Obviously everyone preloads Microsoft's keys and a few vendors preload their own. I'm not sure if any mainstream OEMs preload any of the major Linux distros' keys. Most business desktops and pretty much all DIY hardware supporting secure boot allows you to load your own keys at the system level. Allowing this was a requirement for Windows Logo certification for a while.
If you have a machine that doesn't allow that here's a shim, signed with the Microsoft keys, which can be used to then load anything signed with keys of your choice: https://mjg59.dreamwidth.org/20303.html
Variations on that shim, prepackaged with the vendor's keys and then individually re-signed by MS are used by most major Linux distros to support secure boot.
Those shims will load on any system that can boot current x86 versions of Windows and allow you to run whatever you want.
DanNeely - Thursday, November 23, 2017 - link
When secure boot first came out Canonical was planning to get a version of their boot loader signed by the MS key arguing that making sure that "It just works" for the common user and not having to turn off security features for some enterprise customers were more important than ideological objections to the entire concept. Did they end up following through; or did the plan get waylaid at some point?edzieba - Wednesday, November 22, 2017 - link
So... just delete the MS key from the Secure Boot keystore and load your own, and sign your own bootloader? Why not just USE a security feature as intended?HunterKlynn - Wednesday, November 22, 2017 - link
Yeah this is my understanding. Isn't complaining about requiring SecureBoot like complaining about requiring HTTPS, now that anyone can sign this stuff?adrian_sev - Wednesday, November 22, 2017 - link
for "security reasons" :)) i will just leave this link here : https://techreport.com/news/32867/intel-patches-ne... and a related link http://schd.ws/hosted_files/ossna2017/91/Linuxcon%...