Intel aims to end legacy BIOS support by 2020

by Mark Tyson on 20 November 2017, 09:31

Tags: Intel (NASDAQ:INTC)

Quick Link: HEXUS.net/qadnwl

Add to My Vault: x

Most modern PCs ship with UEFI (Unified Extensible Firmware Interface) as a replacement for the old BIOS (Basic Input/Output System) that used to control the way that your PC boots. UEFI has a number of advantages; allowing you to run remote diagnostics and repair of computers even with no operating system installed - for example, it supports large disks (over 2TB), it is modular, and it uses a CPU independent architecture. Currently your motherboard will feature a 'legacy BIOS' mode that allows you to use software or hardware that might not be fully compatible with UEFI. However, that is likely to be banished on new motherboards by 2020.

The intention to transition to UEFI Class 3 or higher on new motherboards was outlined by Intel’s Brian Richardson in a recent presentation called Last Mile Barriers to Removing Legacy BIOS (PDF). In this document you can read of Intel's intention to depreciate BIOS legacy BIOS support, and new products from then on won't have a CSM (compatibility support module), a component which lets UEFI-unaware operating systems and bootable devices run on newer machines with UEFI.

So, what snags might you experience if you won't have access to legacy BIOS on your computer? First of all 32-bit Windows and desktop Linux distributions require CSM, so those will be no-go areas except running on top of your 64-bit OS, for example. On the hardware side there could be problems for some too - users of 16-bit OpROM devices like older VGA, LAN, and storage. A number of manufacturing / maintenance tools also need updating to remove DOS / BIOS dependences.

Intel is working with partners to eliminate components with no UEFI support and to improve the experience of users with UEFI secure boot to facilitate the phasing out of legacy BIOS support.

HEXUS Forums :: 21 Comments

Login with Forum Account

Don't have an account? Register today!
Posted by afiretruck - Mon 20 Nov 2017 10:09
In a way, I suppose this is a good thing. Most of my booting issues (I run a few Linux distros & Windows 10) are related to accidentally installing in UEFI mode and then trying to boot in BIOS mode, so this'll certainly stop that (as well as force me to finally learn how to GRUB for UEFI)

On the other hand, I don't understand the rationale behind “kill it to death, even though it's disabled by default”. If it's disabled by default, the only people who are going to be using it are those who know what they're doing and are enabling it because they need to.

Also, and finally, this is going to make the entry into hobby OSDev'ing much, much harder on real hardware :( Sure, you can do it in a VM, but nothing beats that feeling of seeing it run on real hardware :D
Posted by Wolfclaw - Mon 20 Nov 2017 11:06
They could even remove AMT while they are at it and secure the bios even more !
Posted by azrael- - Mon 20 Nov 2017 11:45
I do love the bit about the CSM apparently “exposing security risks”. Because UEFI support has been 100% flawless. Or how about that complete access to network functions in the UEFI network stack. Surely, that's no risk at all. We also shouldn't forget that one of the main reason for pushing UEFI (which I actually like btw) is that “old school” BIOS development is slowly becoming a lost art.
Posted by Wozza63 - Mon 20 Nov 2017 11:46
afiretruck
In a way, I suppose this is a good thing. Most of my booting issues (I run a few Linux distros & Windows 10) are related to accidentally installing in UEFI mode and then trying to boot in BIOS mode, so this'll certainly stop that (as well as force me to finally learn how to GRUB for UEFI)

On the other hand, I don't understand the rationale behind “kill it to death, even though it's disabled by default”. If it's disabled by default, the only people who are going to be using it are those who know what they're doing and are enabling it because they need to.

Also, and finally, this is going to make the entry into hobby OSDev'ing much, much harder on real hardware :( Sure, you can do it in a VM, but nothing beats that feeling of seeing it run on real hardware :D

As someone currently building an OS from scratch, I agree with you, although I've never run on the hardware (and probably never will), this removes any chance of me doing so. It's going to make it more difficult for new devs to get into OS development.
Posted by DanceswithUnix - Mon 20 Nov 2017 13:07
afiretruck
Also, and finally, this is going to make the entry into hobby OSDev'ing much, much harder on real hardware :( Sure, you can do it in a VM, but nothing beats that feeling of seeing it run on real hardware :D

I would suggest that anyone learning OS development do so on a Raspberry Pi or similar, ARM u-boot etc skills are useful to have on your CV.

SEE NEWER »