Anytime something (i.e., stack layer, software component, software layer, blob -- in this case, initialization/boot code for hardware which was first simple BIOS'es whcih became larger and more complex BIOS'es which later became still more complex UEFI -- a much larger attack surface by size) in technology is replaced by something new and complex which is touted as "more secure" -- it's usually less secure (bugs and attack vectors are found in hindsight), and minimally, less transparent and understood.
Anyone interested in the subject could Google (or search on their favorite search engine) "UEFI Vulnerabilities" -- for no shortage of issues/problems/security vulnerabilities.
Am I saying that an old BIOS is perfectly secure?
No!
But older BIOSes are an order of magnitude simpler, better understood, and more documented -- than UEFI is at this point.
If UEFI morphs to something else more complex in the future, which it probably will, given the track record of hardware boot/initialization code specifically, and software generally, then my advice at that point in time (10+ years in the future) will be "go back to UEFI, it's simpler, more documented and better understood than what we have now".
But not until that day, and then not unless every computer on the planet is, or has become absolutely incapable of initializing/booting from the older code.
As a generalized pattern/understanding in Software Engineering, older code / older software / older codebases (of whatever form, firmware, etc. -- in this case BIOS hardware init/boot handoff code) -- are generally smaller, simpler (less bloat for approximately the same functionality), vanilla, spartan, better understood, and have had many of their security issues found, fixed, and solved than their present-day over complex and bloated counterparts... (and, did I mention better documented?)
Older BIOSes are much simpler, and also offer no security boundary at all - nobody talks about BIOS vulnerabilities because it wouldn't give you anything you don't already have!
It may be argued that a Ford Model-T (one of the earliest and probably the simplest of all mass-produced vehicles in the early 20th Century: https://en.wikipedia.org/wiki/Ford_Model_T ) had no "security boundary" at all, and that conversely, the most modern vehicle with the latest radio frequency based remote lock and key (aka "Smart Key") -- is more "secure" (has more of a "security boundary")...
...but if so, is that asserted "security boundary" really an actual security boundary(?)
If the security boundary or "security boundary" -- is opaque in how it functions; if it is a "black box": (https://en.wikipedia.org/wiki/Black_box); if no one (other than potentially a few people who work for the manufacturer, or exist at the company subcontracting to build their Smart Key component (if the Smart Key is subcontracted/outsourced)) understands exactly how it works, then is it really "secure"?
(If so, then that sounds eerily similar to the "obscurity is good" (aka "transparency bad") side of the "Security Through Obscurity" debate that the Internet had, like 5, 10, 20+ years ago: https://en.wikipedia.org/wiki/Security_through_obscurity#Cri...)
Why not read the following:
"Gone in 20 seconds: how ‘smart keys’ have fuelled a new wave of car crime":
Perhaps less "security" (less of an asserted "security boundary") -- is actually more actual security -- at least in some cases -- at least in the case of the Ford Model-T...
Anyone interested in the subject could Google (or search on their favorite search engine) "UEFI Vulnerabilities" -- for no shortage of issues/problems/security vulnerabilities.
Am I saying that an old BIOS is perfectly secure?
No!
But older BIOSes are an order of magnitude simpler, better understood, and more documented -- than UEFI is at this point.
If UEFI morphs to something else more complex in the future, which it probably will, given the track record of hardware boot/initialization code specifically, and software generally, then my advice at that point in time (10+ years in the future) will be "go back to UEFI, it's simpler, more documented and better understood than what we have now".
But not until that day, and then not unless every computer on the planet is, or has become absolutely incapable of initializing/booting from the older code.
As a generalized pattern/understanding in Software Engineering, older code / older software / older codebases (of whatever form, firmware, etc. -- in this case BIOS hardware init/boot handoff code) -- are generally smaller, simpler (less bloat for approximately the same functionality), vanilla, spartan, better understood, and have had many of their security issues found, fixed, and solved than their present-day over complex and bloated counterparts... (and, did I mention better documented?)