Researchers Demo Exploits Bypassing UEFI Secure Boot 100
itwbennett writes "Researchers demonstrated at Black Hat this week two attacks that bypassed Secure Boot in order to install a UEFI bootkit — boot rootkit — on affected computers. The first exploit works because certain vendors do not properly protect their firmware, allowing an attacker to modify the code responsible for enforcing Secure Boot, said researcher Yuriy Bulygin, who works at McAfee. The second exploit demonstrated by the researchers can run in user mode, which means that an attacker would only need to gain code execution rights on the system by exploiting a vulnerability in a regular application like Java, Adobe Flash, Microsoft Office or others. In both cases, the exploits are possible not because of vulnerabilities in Secure Boot itself, but because of UEFI implementation errors made by platform vendors."
Of course, a hardware security system that is too complex to verify seems like a fatal flaw.
Hence why UEFI should be dismissed (Score:4, Informative)
Hence why UEFI should be dismissed. If it's useless, just don't implement it, it's cheaper...
TPM is all you need. (Score:5, Informative)
Re: (Score:2, Troll)
UEFI was never intended to improve security. Along with Microsoft's extensions it was designed as a lock-in tool. Too bad we had to wait until it pops up everywhere just to accept reality.
FTFY. There were plenty of warnings, but people like to deny what's there standing in front of their noses.
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot [fsf.org]
Re:TPM is all you need. (Score:5, Interesting)
So far to me it looks like things are playing out exactly as
Re: (Score:2)
Eventually. But Windows 8 is quite toxic enough - it'll be years before they are ready for the next step. Probably around Windows 10.
so an windows 7 UEFI boot loader can come out (Score:2)
so an windows 7 UEFI boot loader can come out
Re: (Score:2)
Eventually. But Windows 8 is quite toxic enough
Except that there really isn't anything wrong with Windows8, except the damned awful UI. If they'd included a classic shell, there wouldn't even be half as much whining over it.
Classic Shell (Score:2)
If they'd included a classic shell
Microsoft did one better by providing hooks for third party developers to create classic shells for Windows 8. I know of at least two classic shells, one of which is actually called Classic Shell.
Re: (Score:1)
Discovery; bundling (Score:2)
Sorry, but if it's not directly built in as a user accessable option, then who cares if the hooks are there.
There is a user-accessible option to open Internet Explorer, type windows 8 classic shell into the Bing search box (which produces this SERP [bing.com]), and click the first result. Or is your complaint that Microsoft provides no means to discover that such a classic shell exists in the first place? If that's true, then the same is true of obscure registry settings that do exist in Windows, and it's true of the existence of web browsers other than IE.
Speaking of IE, Microsoft got in trouble with competition law for
Re: (Score:1)
Windows8 still has lots of problems even without METRO.
As we saw with people still preferring XP today in 2013 that people like me wont ever upgrade from Windows 7 even with classic shell. Too many apps and the hassle is not worth it.
Windows 8 got rid of aero, Windows key + tab browsing, dvd movie playback, rounded corners, and all sane colors. Office 2013 is a horrible horrible GUI that gives me migraines! It is like a fucking time warp back to 1985 CGA/EGA time.
For the extremist design change for MS on Wi
Re: (Score:1)
Eventually. But Windows 8 is quite toxic enough
Except that there really isn't anything wrong with Windows8, except the damned awful UI. If they'd included a classic shell, there wouldn't even be half as much whining over it.
Even if MS decided not to do METRO and had the exact same identical gui we all love in Windows 7 that would not be acceptable as corporations only upgrade every 10 years now. A secure boot is a major hindrance.
Shoot what once took 25 people for 3,000 users 12 years ago, now had 3 or 4 people! WHen you have 3,000 computers there is no time to upgrade without bringing in consultants that charge several hundred an hour for 2 months at a time. It is expensive even if the upgrade is free.
Also what about those wi
Re: (Score:2)
There are two real problems to Windows 8.
First, the lack of any compelling advantage. Windows 7 *works*. Hell, Windows XP still works for a lot of people. What is the killer feature of Windows 8, the one everyone wants? There simply isn't one. People don't like the hastle of changing OS, so they aren't going to do it without a good reason.
Secondly, some business decisions MS made about the direction the company wants to go. From a business perspective, great moves - they are copying the plans already pionee
Re: (Score:2)
What is the killer feature of Windows 8, the one everyone wants?
Smaller memory footprint, generally faster, many CPU optimisations to take into account newer silicon (e.g. being able to switch off unused cores predictably, assigning threads in a sane manner, etc), much better file copy and task manager interface, removing aero in favour of a cleaner UI style, etc.
There's no single big flashy feature added, but there are a lot of nice improvements to Win7. Any for anyone other than those who hunt around the start menu with a mouse rather than using the type-to-run func
Re: (Score:1)
Re: (Score:2)
How many engineers from the Microsoft Corporation does it take to screw in a light bulb?
The answer is zero actually. It doesn't take a single engineer from the Microsoft Corporation, because the Microsoft Corporation simply declares Darkness[tm] to become the new standard.
Re: (Score:2)
I haven't had any difficulty finding desktops and laptops that will PXE boot in UEFI mode (many have both UEFI PXE and BIOS PXE as options in their BIOS settings).
the trouble with UEFI and PXE at the moment is that syslinux and friends (including menu.c32 and ipxe/gpxe) don't support UEFI mode (yet)....so at the moment it's a pain to have working PXE-bootable menus to re-image the machine, run clonezilla, or r
Re: (Score:2)
Note, neither of these has really broken the SB security model itself; they're just attacks against poor implementations of it, which isn't terribly surprising. Firmware, in general, is really fucking terrible code; it's not a surprise at all that some vendors have managed to fuck up their SB implementations.
Re: (Score:3)
I won't speak for Microsoft's intentions, but UEFI Secure Boot is a derivative of trusted-computing designs that are actually designed and intended to improve security. (And for what it's worth, Microsoft Research is actually quite serious about security.)
Re: (Score:2)
UEFI was never intended to improve security. Along with Microsoft's extensions it was designed as a lock-in tool.
Reality check.
An operating system that can be booted from a (U)EFI is called a (U)EFI-aware OS
The Linux kernel has been able to use EFI at boot time since early 2000, using the elilo EFI boot loader or, more recently, EFI versions of GRUB. The distribution Ubuntu added support for UEFI secure boot as of version 12.10. Further, the Linux kernel can be compiled with the option to run as an EFI bootloader on its own through the EFI bootstub feature.
HP-UX has used (U)EFI as its boot mechanism on IA-64 systems since 2002. HP OpenVMS has used (U)EFI on IA-64 since its initial evaluation release in December 2003, and for production releases since January 2005.
Apple uses EFI for its line of Intel-based Macs.
On March 5, 2013, the FreeBSD Foundation awarded a grant to a developer seeking to add UEFI support to the FreeBSD kernel and bootloader
Unified Extensible Firmware Interface [wikipedia.org]
Secure Boot wouldn't a problem for the geek if OEM Linux had a significant share of the x86 desktop.
Re: (Score:3)
UEFI was never intended to improve security. Along with Microsoft's extensions it was designed as a lock-in tool.
Reality check. ...Secure Boot wouldn't a problem for the geek if OEM Linux had a significant share of the x86 desktop.
It looks like your post was intended to show the prior commenter was "not in touch with reality", however what you actually did was confirm that he was right. Your conclusion states "Secure Boot wouldn't be a problem ...if...", which pretty explicitly states that Secure Boot is a problem. Your conclusion is actually confirming that lock in problem of Secure Boot, regardless of what anyone claims the intent was, and regardless of any arguments over whether the system is otherwise noble or malicious.
And yeah,
Re: (Score:2)
Why should a firmware bootloader impose any difficulty on an OS based on popularity? What of the next great OS that has a total user base of one developer?
If secure boot wasn't designed to be more lock-in than secure (or alternatively, wasn't designed so poorly) it would never be a problem for the owner of a system to securely boot anything of their choice WITHOUT turning the protection off. The problem is in who does/can sign the bootloader.
Were it properly designed, there would always be at least an owner
Re: (Score:2)
Why is there no "this is completely factually incorrect" mod tool? Seems like an oversight.
UEFI is a firmware standard. It was deployed in the real world in production systems for years before anyone started drafting Secure Boot. Secure Boot is one part of the UEFI standard, but UEFI is complete without it, and indeed SB was only added in UEFI 1.2.
If you want to talk about SB, talk about SB. Don't confuse it with UEFI per se.
Re: (Score:2)
Everyone know nerds knows everything.
This is a site for nerds.
Since its factual incorrect its not written by a nerd but rather by either a Troll and probably is some Flamebait.
Select one of them.
I have a third exploit (Score:2)
Yep. TPM really is a better design than what's in UEFI. The attack surface against UEFI is quite big.
I actually have a third exploit against part of the whole Secure Boot process, this time a Microsoft bug in Windows itself that lets me load unsigned kernel code at boot time with Secure Boot enabled.
This flaw works on all architectures, so I'm saving it for now. I found it trying to find a new jailbreak for Windows RT 8.1.
Re:Hence why UEFI should be dismissed (Score:4, Insightful)
That's like saying metal should be dismissed because one application is the building of nuclear bombs.
UEFI's just a more modular/uniform sort of BIOS. Even the old 16-bit BIOSes could have had anti-competitive restrictions bolted on, but it wouldn't have been as easy to sell.
Re: (Score:1)
"could have" != did
UEFI *does*. Sure, you can switch off the secure boot FOR NOW. But how long until MS decides that other OS's are too "insecure" and insist on secure boot to be on all the time and start being parsimonious with their keys?
Wake up.
Switching to competitor requires a competitor (Score:3, Insightful)
Re: (Score:1)
GUI unfamiliarity wasn't all of it (Score:2)
[People who bought a GNU/Linux netbook tended to be unsatisfied] because they didn't know how to use Linux. They'd buy the machine, get it home, unbox it, boot up, then suddenly ask 'What the hell is this crap?' and 'Why can't I install my software?'.
Unfamiliarity with the GUI didn't stop people from taking to the iPad. The reason has to be more subtle.
Re: (Score:1)
Re: (Score:2)
Eh? If for some reason the baby was thrown out with the bathwater because of your bitching, then MS would just step up their game and "insist" on a variant of secure boot on whatever system replaced it.
Re: (Score:3)
> UEFI's just a more modular/uniform sort of BIOS.
I don't know. The BIOS usually seems to work, whereas UEFI usually has so many bugs (in my experience) that it is hard to get to work. So if you find bugs without looking for them, that would indicate that you can find even more if you are looking for them, most likely with security implications.
Some people say that UEFI is too complex - and the evidence seems to support that notion. All a boot loader has to do is to load a binary from disk into RAM and e
Re: (Score:2)
Technology marches on. Bootstrapping a PC by pounding a signal up hardware interrupt lines used in ISA just isn't a good way to start up hardware that doesn't even have ISA, and hasn't for years. UEFI finally does away with that, so that the OS doesn't have to waste time remapping every single thing BIOS does on boot anymore. It also allows you to read from the disk using transfer rates that rent a throwback to the 1980s until you load mass storage drivers.
It might come as a shock that most gains in boot
Re: (Score:1)
That's like saying metal should be dismissed because one application is the building of nuclear bombs.
No, it's like saying nuclear bombs should be dismantled because they cause folks to want to blow our shit up.
UEFI's just a more modular/uniform sort of BIOS.
No you fucking ignorant fool. That's EFI. The U in UEFI is the Useless part. Inform yourself; You sound retarded.
Even the old 16-bit BIOSes could have had anti-competitive restrictions bolted on, but it wouldn't have been as easy to sell.
More ignorant nonsense. UEFI is inflexible and overly complex. The OS has to kick off encryption chains and verify all loaded executable code anyway to utilize its features. So what if the boot image is verified if the rest of the Kernel isn't?
Look, I'll make this really fucking ea
Re: (Score:2)
Hmm... You wouldn't necessarily have to implement a patent encumbered FAT-32 file system either. UEFI is supposed to work with FAT-16 and FAT-24, but I've only found FAT-32 to be even remotely reliably supported.
The El Torito CD Boot standard [wikipedia.org] solves the 540 byte boot-strap loader limit, and utilizes a file format that could just as easily be used on magnetic boot media. It's also in wide use. UEFI is the most round-about proprietary solution for a problem I've ever seen. It's like dropping everythin
Re: (Score:2)
s/540/446/
446 = 512 - 2 - 64
512 sector.
2 for 0xAA 0x55 boot magic number
64 for partition table.
Re: (Score:2)
UEFI proprietary? Since when?
https://en.wikipedia.org/wiki/Extensible_Firmware_Interface [wikipedia.org]
https://en.wikipedia.org/wiki/Unified_EFI_Forum [wikipedia.org]
from the latter:
"The Unified EFI Forum or UEFI Forum (where UEFI stands for Unified Extensible Firmware Interface) is an alliance between several leading technology companies to modernize the booting process. The board of directors includes representatives from eleven "Promoter" companies: AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Micro
Re: (Score:1)
1. "EFI" has been deprecated for over 7 years, champ. UEFI was just a renaming to reflect the fact that it was no longer Intel's pet project but would be maintained by a consortium (U=Unified under the UEFI Forum);
2. The UEFI Forum doesn't exist to plot evil and make impotent nerds like you angry, but to develop the whole UEFI specification;
3. The secure boot bollocks in UEFI is optional. Of course there must be a chain of loaded binary verification for it to be meaningful - what else did you expect?
4. If y
Re: (Score:2)
Obviously said by someone who didn't use PCs much in the past.
Laptops were notorious for having proprietary bits in their BIOS - some won't even boot unless you put in their specific version of MS-DOS.
Hell, even these days you find laptops that complain on bootup when they don't find an "approved" hard drive [thinkwiki.org].
Anyhow, it's time to move away from the crap that is BIOS - besides 16-bit i
Re: (Score:1)
*All* BIOSes have "proprietary bits" in the sense of offering services peculiar to that brand, and many of the older INTs were just de facto standardised - unique features weren't supported as often as ubiquitous features, because that just meant more work for the OS designer. I've got systems sitting around back to an IBM AT, and have certainly wasted way too much time fiddling with the idiosyncracies of old systems!
But trying to convince manufacturers of an existing system to add a particular feature whic
Re: (Score:3, Insightful)
Re: (Score:1)
Also, we should just get rid of the ignition keys for cars, since some of them can be hot wired. On an unrelated note, whereabouts is you car?
You fail to understand the problem, in a car YOU have the key, with UEFI, a great deal of organisations (MS, BIOS vendor, MB vendor, HW vendors like Dell/HP/Lenovo/...) have the key to your computer - we dislike the fact that as the rightfull owners of those computers, we seem to be the only ones NOT having a key.
If you want a car analogy, it is more like not having a "key" for the filler cap, wheel bolts, engine,... You can start, you can drive, but you can not replace parts, use other fuel supplier, do yo
Re: (Score:2)
You fail to understand ... the dealer you bought your car from ... can make a key on demand.
And you too can have the and control the Secure Boot key, if only you'd take a moment to learn rather than parroting other slashdot moron posts.
You can simply choose not to buy a Secure Boot implementation that doesn't let you control the key if you want, and buy one that does give you the key.
Its really not hard unless you're being an over-reacting fanboy, otherwise known as an RMS tool.
Re: (Score:2)
You can simply choose not to buy a Secure Boot implementation etc.
He said simply...
Re: (Score:2)
You DO know that many new cars these days have no ignition key, don't you?
Apparently they could be hot-wired so now they use an electronic authentication and a push button.
Re:I favor UEFI (Score:2)
Just not how it is implemented with MS as the gatekeeper with the private key.
I hate the BIOS. It is 30 years old, archaic, has weird instructions such as do not use more than 1 meg of ram, and many hacks and patches to get around the original 30 year old hacks like the 1 meg limit, etc. ACPI for a fucking decade never quite worked! Linux got blamed because companies like Dell did things a little differently with their ACPI so when the computer went to sleep sound would not work when it came up etc.
Remember
Re: (Score:2)
Amen
Re: (Score:2)
OF course slashdotters blamed XP, but investigation showed the IRQ conflicts were caused by crappy ACPI.
You'll no doubt be pleased to hear that UEFI still requires ACPI in all its crappy glory.
Re: (Score:2)
... You realize that if we dismissed everything that had an implementation flaw in one or two of the hundreds of different implementations or more ... we'd never have any progress.
A new tire blows out just minutes after being installed. Does that mean tires are all useless?
Your post isn't informative, its ignorant. It wreaks of uneducated fanboy.
Re: Hence why UEFI should be dismissed (Score:2)
Re: (Score:1)
Useless? It is actively harmful. UEFI is far more likely to corrupt the operating system than the usual SMBIOS (system management mode BIOS), _and_ the sheer incompetence of the people implementing UEFI is... daunting. Just take a look on the absurd bugs Linux and FreeBSD have to work around (Windows does as well, but you won't find a changelog telling you the gore details).
The proper amount of running firmware after the platform manages to run the bootloader is *zero*.
Holy crap.
Don't you remember Dells not working hibernating properly, Linux not even fucking boot up on some boards, IRQ conflicts, BSOD, all related to fucking ACPI bios!
The bios is unstable, full of hacks, 30 years old, has esteroic things like limit ram to 1 meg, then more esoteric things like no_really_use_more_than_1meg_of_ram_but_use_this_hack_for_compality_with_dos_2.1, and years and years of garbage.
ACPI is the main reason Linux does not work to do thanks to the bois. It is time to switch to EFI so L
Re: (Score:2)
Yeah, but the IBM bios that everyone's been using/extending since the 1980's just isn't going to cut it going forward.
UEFI can and could've been a wonderful suite of tools to allow OS vendors to make life easier for the average user. Dragging our feet because the PC BIOS has been comfortable and what we're used to isn't progress.
Re: (Score:1)
Re: (Score:2)
UEFI is quite useful and is pretty much in every PC made since 2005 or so. Intel has stopped making BIOSes for their CPUs and only makes UEFI boot software available. This has been true since the Core series of CPUs were released - Core Solo/Duo, etc. It existed a few years prior to Apple using Intel CPUs.
In fact, what you know as the "bios" today is really UEFI running a BIOS emulator.
But UEFI offers many advantage
Re: (Score:2)
Bad implementations of security are vulnerable (Score:3)
Film at 11.
Verification (Score:2)
"Of course, a hardware security system that is too complex to verify seems like a fatal flaw."
Why is that? We cannot verify that CPUs do not have "secret knock" codes. Is that a "fatal flaw"? All it really means is that you can't be sure that your CPU isn't performing any malicious activity. The best you can do is trust that it isn't. I suppose you could spend all your time looking for such evidence, but you still wouldn't be able to prove a CPU isn't performing malicious activity in exactly the same way
Re: (Score:3)
Does this mean I can't install Linux or Windows 7 on a UEFI Secure Boot machine? (Newbie here)
It depends. You usually can, in a BIOS-compatibility mode, which most offer. But those can be buggy and/or incompatible. I have a server that can't go over 2GB of RAM in the Xen Dom0 because of lack of support for the UEFI memory space, which is beyond the BIOS compatibility region apparently.
Some of the distros have gone hat-in-hand to Microsoft to get their own keys to avoid such issues. That work is leading
Re: (Score:2)
Some implementations correctly enable you to simply turn off Secure Boot but otherwise leave UEFI (and the rest of the BIOS) intact.
A method of disabling Secure Boot is required by the spec and by Microsoft. It may not be implemented well, but then, that's true of every component of the BIOS.
Being able to install your own keys is a great feature, because actually having a verifiable boot chain can be a pretty useful security tool.
Required in Windows 8; forbidden in Windows RT (Score:5, Interesting)
A method of disabling Secure Boot is required by the spec and by Microsoft.
In Windows 8 (x86 and x86-64), it is required. In Windows RT, it is forbidden. And other comments to this topic speculate that Microsoft is likely to license Windows 10 like Windows RT in this respect.
sever that is locked to win 8 / 2012 or 2gb ram? (Score:2)
Do tell who made made this piece of shit.
Re: (Score:2)
>Microsoft's spec is supposed to allow people to install their own keys
The Windows 8 certification requirement outright mandates that users are able to upload their own keys. (See here [microsoft.com], "Windows 8 System Requirements", page 121, paragraph 17.)
This thankfully gives us a pretty solid standing to complain at hardware makers who don't do it right.
In the long run, I am not sure it will be necessary, though. I've been looking into those issues after getting a laptop with SecureBoot enabled, and sane options ar
Re: (Score:1)
Yes.
Besides the secure boot bit, Windows 7 is UEFI friendly. What you need to do is go into the bios or setup when you first turn it on and disable secure boot and you are good.
Man, if it were not MS being the only C.A. secure boot would be a great standard for Linux, FreeBSD, and WIndows 7.
Re: (Score:2)
Then set up another CA. Microsoft isn't stopping anyone from doing it.
Re: (Score:1)
But doesn't only Microsoft have the private keys used for secureboot?
Also how do you add keys? A nightmare scenario would be where malware signs its bootkit in it making it impossible to remove!
Sun had pins with its firmware updates where by default it is set read-only and can move them to flash an update. Maybe something like this or a secure USB flash could be used and the EFI could refuse to load the keys any other way?
Re: (Score:2)
"But doesn't only Microsoft have the private keys used for secureboot?"
Not in the sense you think it does, no. When people say this, what they mean is 'Microsoft is the only company that has decided to act as a CA for Secure Boot and ask hardware vendors to ship its keys in their firmware implementations'. Anyone else could choose to try and do this as well; no-one else has. Secure Boot per se is simply a definition of a system by which a firmware can use public key-based cryptography to validate a boot cha
Re: (Score:2)
You can get your own signing key from Verisign. It is up to each OEM to properly implement UEFI on its motherboards; the EFI and later UEFI standard and its revisions have been open and freely available from the start.
IF an OEM properly implements UEFI and the secure boot portion then you will be able to boot any OS which ships with a valid key, or use your personal signing key to vouchsafe any OS you choose. Far as I can tell the problem lies entirely with OEMs that have lazy, improper, or incompetent im
Re: (Score:2)
"You can get your own signing key from Verisign." ...which is acting as an agent for Microsoft. That's the whole program we're talking about, that was set up by Microsoft: they will sell you the right to have your boot chain signed by a key that's signed by their key, as long as you can jump through some fairly basic 'good actor' hoops. The reason you would do this is that most SB enabled systems trust those keys, because Microsoft's OEM requirements require them to trust those keys.
The point I'm making is
Re: (Score:2)
Absolutely agreed.
As I am trying to understand it, if the OEM sets up UEFI and SB properly, I should be able to insert my own signing key, not just one that's been pre-authorized, whomever I got it from.
I hope that finding an OEM that does this right when I get my next mobo rather than just drinking Remond-flavored Kool-Aid is not going to be too much of a hassle, but I suspect otherwise.
Re: (Score:2)
Well, that's interesting, because at least in theory, if you want to be sure you can set up your own keys, you should actually buy a system that has the 'Redmond-flavored Kool-Aid': Microsoft's Windows 8 OEM licensing requirements actually specifically state that the firmware must allow access to SB Setup Mode, which is what you use to configure your own keys.
The UEFI / SB spec itself, IIRC, does not in fact require this - it defines and describes Setup Mode, but IIRC, doesn't actually require that the user
Re: (Score:2)
That last para got a good laugh out of me, thanks!
I agree, particularly in that it seems that much will depend on what a given OEM will deliver. I am unsure exactly what the spec requires about access to setup mode; my reading of the relevant stuff on Wikipedia, openboot, and a few other places has left me confused - and I admit much of the discussion was a bit over my head to begin with.
I really dislike being in the situation that my best reaction to an impending situation is summed up with: "Aw, shit."
Re: (Score:1)
not right now but the black hats are working on ways to allow it so you can make that worthless Microsoft surface pro scream on Red hat
We need another layer of bootkit protection! (Score:2)
Clearly what we need here is another, lower layer of bootkit protection to protect UEFI secure boot.
(100 years later....)
"Oh no! All 6000 layers of bootkit protection have been breached!"
"Those fools! If only they'd given it 6001 layers! When will they learn!?"
UEFI greatly increases comlpexity (Score:2)
Increases in complexity are usually increases in security vulnerabilities.
Also, boot times and installation are now longer and more complex...and just like the NSA, we are still no better in our security.
What a horrible joke.
Re: (Score:1)
Increases in complexity are usually increases in security vulnerabilities.
Also, boot times and installation are now longer and more complex...and just like the NSA, we are still no better in our security.
What a horrible joke.
Have any evidence?
I am in favor of it because it reduces complexity by throwing out XT, 286, and, extended vs expanded ram code, and other legacies of old. Slashdot favored EFI too before Windows 8. If it were not for just having MS as the C.A. for the signing bootkey I think it would be great.
UEFI is just firmware and is fairly simple. Nothing else without the legacy junk and poor ACPI chunks that Linux does not support correctly due to motherboard makers not following the spec (Dells not having sound afte
UEFI will hinder my testing of embedded (Score:3)
Right. (Score:2)
"Of course, a hardware security system that is too complex to verify seems like a fatal flaw."
Then again, who is telling us that they actually bothered to verify anything? Where exactly does this assumption come from that the system is too complex to implement?
You can write buggy and flawed software in any language, framework and system - regardless of its ease of use.
Security vs. usability vs. cost (Score:1)
You get to pick 2 ... on a good day.
Re: (Score:2)
OpenBoot/OpenFrimware
Yeah, it'd be nice. One problem, I think, was timing. By the time open source started becoming reputable and acceptable by business the EFI was too far along. Another, related, was the amount of effort going into OpenBoot couldn't begin to match the industry-group efforts. I think it's a shame, but too little, too late (not the work itself, but the acceptance of it as valid).
coreboot (Score:1)
flawed but successful (Score:2)
as long as it makes it more difficult to run or install linux or *bsd or other alternative operating systems, then it has done its job.
i always thought that Restricted Boot was created to advance the interests of Microsoft and the RIAA....but it wouldn't surprise me if the NSA was behind it too.
UEFI Garbage (Score:1)
I guarantee you very shortly after UEFI was even thought about the NSA would be at their door with a mandated back door, and covered by NSL Letters! So UEFI is protection from insecure boot, except if the Gov. wants in.