Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Researchers Demo Exploits Bypassing UEFI Secure Boot

Unknown Lamer posted about a year ago | from the didn't-see-that-one-coming dept.

Bug 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.

cancel ×

100 comments

Sorry! There are no comments related to the filter you selected.

Hence why UEFI should be dismissed (4, Informative)

Nikademus (631739) | about a year ago | (#44464651)

Hence why UEFI should be dismissed. If it's useless, just don't implement it, it's cheaper...

TPM is all you need. (5, Informative)

boorack (1345877) | about a year ago | (#44464655)

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 realize it.

Re:TPM is all you need. (1, Troll)

dmbasso (1052166) | about a year ago | (#44464715)

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. (5, Interesting)

Vanderhoth (1582661) | about a year ago | (#44464735)

I don't know who this "we" you're talking about is. Every comment section for every article on UEFI and secure boot that was posted on /. was filled with commenter saying it was useless, would be bypassed within a year and was how MS was going to use it to lock average people into Windows. Followed by reams of MS shills saying it was only mandatory on ARM devices and it can be turned off on anything else. Followed by more posts of "Until MS requires it and it can't be turned off".

So far to me it looks like things are playing out exactly as /. predicted. Looks like the next step will be for MS to just require it on everything, even though it doesn't work.

Re:TPM is all you need. (1)

SuricouRaven (1897204) | about a year ago | (#44464815)

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 (1)

Joe_Dragon (2206452) | about a year ago | (#44465013)

so an windows 7 UEFI boot loader can come out

Re:TPM is all you need. (1)

Mashiki (184564) | about a year ago | (#44465163)

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 (1)

tepples (727027) | about a year ago | (#44465205)

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:Classic Shell (1)

Sable Drakon (831800) | about a year ago | (#44465265)

Sorry, but if it's not directly built in as a user accessable option, then who cares if the hooks are there. Mashki's right, if Win8 had a setting to completely turn off the 'Metro' UI elements and gave a Win7 shell, there'd be a lot less complaints about it.

Discovery; bundling (1)

tepples (727027) | about a year ago | (#44465669)

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 including things with Windows. I'm guessing this is why Microsoft declined to ship MSE bundled with Windows XP, Windows Vista, and Windows 7 so as not to be perceived as using its Windows market power to gain antivirus market power.

Re:Discovery; bundling (1)

Billly Gates (198444) | about a year ago | (#44465809)

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 Windows 8/Office 2013 look here [tutsplus.com] . I can understand skeumorphism might not always be ideal, but it dam looks nice and not extreme like blinding white voids of color that MS is taking with METRO.

Until this is fixed I am staying with Windows 7 regardless of whether Metro is in it or not.

Re:TPM is all you need. (0)

Anonymous Coward | about a year ago | (#44465515)

Your post didn't make any sense to me. I had to come up with my own car analogy.

There is a broken down, barely working car with incomplete history of numerous returns to the shop and you are not allowed to look under the hood. But it has a great paint job so I know you'll like it.

How'd I do?

Re:TPM is all you need. (1)

Billly Gates (198444) | about a year ago | (#44465745)

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 with apps that run on Linux or Unix or even Windows 7 only? XP apps for example run under virtualPC for Windows 7 pro/enterprise. Not to mention Windows 8 can not even play DVD movies?! It really is a terrible operating system and what they did with aero is a travesty ... regardless of the practical problems of upgrading.

Re:TPM is all you need. (1)

SuricouRaven (1897204) | about a year ago | (#44466451)

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 pioneered by Apple an Google. Rather than simply making an operating system, MS is now focusing on the entire ecosystem. A family of OSs to cover everything from your mobile phone to a server, all in a unified framework. Easy porting of software between them. An app store. Windows becomes more than just a utility, it becomes a way to promote a wide variety of products. From the perspective of the end users though, these are just more annoyances - a change of interface for no apparent reason (Until you realise MS are aiming for a unified interface across all devices), Apple-style restrictions on software installation start appearing (The typical end-user has no idea that 'Windows RT' is anything other than windows for tablets), and the prospect of Secure Boot ready to screw up imaging procedures and that ever-worrying threat that one day the ability to boot a non-Windows OS may be taken away entirely.

MS must have known about the backlash that would come from introducing metro and from causing confusion with a not-really-windows ARM version under the same name. I think this is their strategic approach: They are making an OS that they know everyone is going to loathe, because even by failing it'll secure an advantagious position for Microsoft in the future.

Re:TPM is all you need. (1)

EdZ (755139) | about a year ago | (#44466929)

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 function that's been there since Vista, it takes all of 10 minutes to get used to (or to install a start-menu replacement for the luddites).

Re:TPM is all you need. (1)

munwin99 (667576) | about a year ago | (#44468593)

Edz, you just disproved your own point. No normal user I know gives a crap about any of those features. Tech users, yeah, sure. Normal users, no way. NONE of them make the pain and expense of an upgrade worthwhile. Pain because things change and they have to relearn them. Expense because upgrading costs money for the OS and (usually) money to have someone do it for them. Add to that the fact that the press and others have written off the interface (no comment on it from me here) and they see no compelling reason to spend money for something they don't care about and which they have been told is bad.

Re:TPM is all you need. (1)

SpzToid (869795) | about a year ago | (#44464863)

Looks like the next step will be for MS to just require it on everything, even though it doesn't work.

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: TPM is all you need. (0)

Anonymous Coward | about a year ago | (#44464939)

How many engineers from the Microsoft Corporation does it take to screw in a light bulb?

How many executives from the Microsoft Corporation does it take to screw up a light bulb? Any one of them can and will if given the chance.

Re:TPM is all you need. (0)

Anonymous Coward | about a year ago | (#44465339)

It will be hard to require it on everything at this point. UEFI is still pretty half-baked when it comes to the enterprise. I've recently had to work on this some and here is what you get:

1) UEFI can only boot from FAT32 partitions - so max file size 4 GB when enterprise images are easily 7 GB+
2) You can't easily PXE boot to UEFI mode as almost no desktop / notebook network cards support it.

Taken together, this means you cannot really deploy a corporate image using UEFI mode. If I can't install it from a USB boot (since the image is 8 GB and Windows 8+ no longer let you split your image into multiple files like you could with Windows 7), and I can't install it from PXE boot (WDS, etc.) because you can only install UEFI mode when booted to UEFI mode, then it is a complete non-starter.

I did work out workarounds like booting from one USB key (FAT32) and then inserting a second key (NTFS) to install the image from - but that is just ridiculous to have to do in production. Sure, you could boot from a FAT32 USB key and then map a network drive and install from there, but again that isn't how you drive mass enterprise deployments.

Re:TPM is all you need. (1)

cas2000 (148703) | about a year ago | (#44482059)

2) You can't easily PXE boot to UEFI mode as almost no desktop / notebook network cards support it.

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 run an installer ISO.

some things still work - anything that doesn't need to stay in UEFI mode. e.g. freedos floppy images for motherboard or PCI-e card firmware updates. installers and re-imaging tools won't work because they need to be in UEFI mode to change the UEFI boot settings.

this makes it a real pain to script/automate the re-imaging of large numbers of machines (e.g. an entire lab of Windows PCs at the start of semester). it has turned turned what used to be an entirely automated remotely triggered process that can re-image an entire lab in under an hour into a tedious manual process booting each machine individually with a USB stick, and then sitting through the entire re-install process.

the good news is that the ipxe and syslinux devs are working on it, so i expect it will be working properly by the end of the year.

BTW, all this is slightly off-topic as it isn't specifically about Restricted Boot...it's just an issue with UEFI itself at the moment.

Re:TPM is all you need. (1)

AdamWill (604569) | about a year ago | (#44465535)

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:TPM is all you need. (2)

blueg3 (192743) | about a year ago | (#44464949)

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:TPM is all you need. (0)

Anonymous Coward | about a year ago | (#44465259)

UEFI is indeed part of the implementation of trusted-computing. They don't really want to call it that because it was a PR failure.
But it isn't about security. It is about DRM and as a happy circumstance DRM requires a closed source operating system, so Microsoft is happy to implement it.

Re:TPM is all you need. (-1)

Anonymous Coward | about a year ago | (#44465543)

(And for what it's worth, Microsoft Research is actually quite serious about security.)

Based on past experience, I would say Microsoft Research's thoughts on security are not worth anything.

Re:TPM is all you need. (1)

westlake (615356) | about a year ago | (#44465295)

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:TPM is all you need. (2)

Alsee (515537) | about a year ago | (#44465879)

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, TrustedComputing&Secureboot are a truckload of extremely malignant problems even if Linux were a majority share of desktops.

-

Re:TPM is all you need. (1)

sjames (1099) | about a year ago | (#44466021)

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 key and an OEM key. The bootloader and OS could ask whose key was used to authenticate the boot (and check key fingerprint, etc). The owner could ass/subtract keys at will.

Re:TPM is all you need. (1)

AdamWill (604569) | about a year ago | (#44465519)

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:TPM is all you need. (1)

a_n_d_e_r_s (136412) | about a year ago | (#44467199)

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 (1)

Myria (562655) | about a year ago | (#44466099)

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:TPM is all you need. (0)

Anonymous Coward | about a year ago | (#44470309)

We need to take over Microsoft Windows using eminent domain and make it public property. In all of legal history there has never been any piece of property that more numbers of people are dependent on, and hence providing justification for the use of eminent domain, than this one.

The stockholders have had plenty of opportunities to make a reasonable profit from this property, and Microsoft has repeatedly demonstrated its inability to operate and maintain this property in a manner consistent with the public good.

Re:Hence why UEFI should be dismissed (3, Insightful)

Joining Yet Again (2992179) | about a year ago | (#44464679)

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:Hence why UEFI should be dismissed (0)

Viol8 (599362) | about a year ago | (#44464703)

"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.

Re:Hence why UEFI should be dismissed (0)

Anonymous Coward | about a year ago | (#44464709)

So then we only get machines which cannot run the Secure Boot feature.

Switching to competitor requires a competitor (2, Insightful)

tepples (727027) | about a year ago | (#44465175)

Good luck finding new "machines which cannot run the Secure Boot feature" at an affordable price once virtually every name-brand home PC not made by Apple ships with Secure Boot turned on in Windows-only mode. The last time GNU/Linux had a reasonable chance to ship on home PCs was netbooks, and Microsoft quickly killed that by offering deeply discounted Windows XP licenses for ULCPCs.

Re:Switching to competitor requires a competitor (1)

Sable Drakon (831800) | about a year ago | (#44465263)

No, consumers killed it 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?'. Once they discovered that they can't easily get their stuff to run, the netbooks were almost immediately returned. Microsoft didn't have to do anything to kill Linux on netbooks, anyone saying so is just another 'MS is Evil' spouting moron.

GUI unfamiliarity wasn't all of it (1)

tepples (727027) | about a year ago | (#44465677)

[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:GUI unfamiliarity wasn't all of it (1)

Sable Drakon (831800) | about a year ago | (#44465759)

That's because the iPad's GUI was already well known and documented by the time it was launched, thanks to the first two iPhones. It also helped that Apple designed iOS at that point in time to be idiot proof for 99% of their active and potential customers. Linux isn't that idiot proof yet, regardless of all that's been done to make it so.

Re:Hence why UEFI should be dismissed (1)

Joining Yet Again (2992179) | about a year ago | (#44465093)

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:Hence why UEFI should be dismissed (2)

thsths (31372) | about a year ago | (#44465125)

> 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 execute it. BIOS got that right - but unfortunately the boot sector of 512 bytes is way too small for modern software. Let the boot loader say how long it is, and load everything into RAM. Any decent kernel can deal with the rest, using hardware discovery etc.

Re:Hence why UEFI should be dismissed (0)

Anonymous Coward | about a year ago | (#44466663)

You're attempting to construct a deductive logical argument but you're using probabilistic unsubstantiated statements. That is a fail on your part since you don't have any actual data. WIthout that data "would indicate", "some people" , "most likely" are not phrases that are of any use in a technical argument.

All a boot loader has to do is to load a binary from disk into RAM and execute it. BIOS got that right - but unfortunately the boot sector of 512 bytes is way too small for modern software. Let the boot loader say how long it is, and load everything into RAM. Any decent kernel can deal with the rest, using hardware discovery etc.

lol

Re:Hence why UEFI should be dismissed (1)

MachineShedFred (621896) | about a year ago | (#44467061)

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 time in the last 3 years are directly attributable to UEFI, and customers want faster booting computers.

Because of one module, forced on the world by Microsoft, UEFI is getting a bad rap. Never mid that it has been successfully used on systems long before Secure Boot was even a concept, and is still implemented on systems without anything approaching the crapware known as Secure Boot.

Re:Hence why UEFI should be dismissed (1)

Anonymous Coward | about a year ago | (#44466719)

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 easy for your small mind to comprehend: All we need is a BIOS option to permit the OS to flash some of its /boot/ into firmware on next boot.
[x] Allow OS install on next boot.

THAT'S IT! That's ALL. It's every bit as secure as UEFI, doesn't require some retarded hex code entry you will fuck up. Can be secured via standard BIOS password, and allows the OS to BOOT INSTANTLY and Optionally kick off its signing verification chain.

For fuck's sake. It even already exists! [coreboot.org] To see if my /boot/ configuration optimizations make improvements I have to measure my start-up time in Millseconds not Seconds!

Re:Hence why UEFI should be dismissed (1)

VortexCortex (1117377) | about a year ago | (#44466861)

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 everything to forge a hammer just to force a nail in place instead of just using the screws and drill in your hands.

Re:Hence why UEFI should be dismissed (1)

VortexCortex (1117377) | about a year ago | (#44466877)

s/540/446/

446 = 512 - 2 - 64
512 sector.
2 for 0xAA 0x55 boot magic number
64 for partition table.

Re:Hence why UEFI should be dismissed (1)

kermidge (2221646) | about a year ago | (#44470959)

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, Microsoft, and Phoenix Technologies."

and

"The non-profit corporation has assumed responsibility for the management and promotion of the Unified Extensible Firmware Interface (UEFI) specification, a bootloader and runtime interface between platform firmware and an operating system. The original EFI specification was developed by Intel and was used as the starting point from which the UEFI version(s) were developed. The goal of the organization is to replace the aging PC BIOS."

If by proprietary you mean there are companies involved in it, yeah, well, ok. If you mean they do it to achieve some kind of lock-in, nefarious or no, then what the companies are doing doesn't seem to me to rise to the definition.

Also, on secure boot, Microsoft is pushing their own implementation of it; the real problem is and will be getting OEMs to not lock their machines to the need for a Microsoft key and properly furnishing the UEFI and secure boot provisions. In other words, we have to depend on the various OEMs to not screw things up. Best I can figure, secure boot itself - provided that there is not indeed an inherent, un-fixable security hole, can be useful in helping to prevent one's machine from getting owned by miscreants (or mal-doers or villains, et al.)

Perhaps relevant, from the first article,
"Several major Linux distributions have developed different implementations for secure boot. Matthew Garrett himself developed a minimal bootloader known as shim; a pre-compiled, signed bootloader that allows the user to individually trust keys provided by distributors.[57] Ubuntu 12.10 uses an older version of shim pre-configured for use with Canonical's own key that only verifies the bootloader and allows unsigned kernels to be loaded: developers believed this practice of only signing the bootloader is more feasible, since a trusted kernel is only effective at securing user space and not the pre-boot state (which secure boot is designed to protect). This also allows users to build their own kernels and use custom kernel modules as well, without needing to re-configure the system.[58][40][59] Canonical also maintains its own private key to sign installations of Ubuntu pre-loaded on certified OEM computers that run the operating system, and also plans to enforce a secure boot requirement as well—requiring both a Canonical key and a Microsoft key (for compatibility reasons) to be included in their firmware. Fedora also uses shim, but requires that both the kernel and its modules be signed as well.[58]"

Btw, Microsoft is not who furnishes the keys - one gets them from Verisign for ~$100 for an individual, just like Microsoft did. If I get accepted into senior housing I'll be able to afford to get my very own key, which I intend doing.

Re:Hence why UEFI should be dismissed (1)

Joining Yet Again (2992179) | about a year ago | (#44471671)

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 you think UEFI is overly complex, you should try writing a 16 bit subsystem. And a PC BIOS is only "flexible" in the sense that basic secondary storage/network /system stuff was de facto standardised ages ago and for everything else someone will have written a driver to make the appropriate random INTs;

5. "All we need is a BIOS option to permit the OS to flash into firmware" - I think you've lost the plot here completely, champ, but you appear worried about someone manually typing in a key wrongly while not having a problem with a "flash random user code to firmware" BIOS option.

Re:Hence why UEFI should be dismissed (1)

tlhIngan (30335) | about a year ago | (#44486557)

Even the old 16-bit BIOSes could have had anti-competitive restrictions bolted on, but it wouldn't have been as easy to sell.

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 issues, the MBR's had its day (it can't support >2TiB drives), and booting by loading 128kiB of code that randomly hooks the BIOS is always calling for trouble. Like how you could boot form internal disk, onboard disk controller, external disk controller, NIC, or CD, but only one of them because the BIOS ROM hooks would get overridden and strangeness ensues. At least with everything integrated the BIOS could be written without needing ROM expansions so you can boot off floppy, CD, NIC, USB and then internal disk controllers without having to enable individual ones.

Hell, a better BIOS that enumerates things properly would be a dream - having disks that initialize the same way every time in whatever OS you use so the first disk in the system would be the first disk Linux and Windows sees.

Re:Hence why UEFI should be dismissed (1)

Joining Yet Again (2992179) | about a year ago | (#44486963)

*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 which is bound to piss off the users is harder than trying to incorporate a feature to a new standard.

Re:Hence why UEFI should be dismissed (3, Insightful)

v.dog (1093949) | about a year ago | (#44464755)

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?

Re:Hence why UEFI should be dismissed (0)

dna_(c)(tm)(r) (618003) | about a year ago | (#44464901)

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 your own maintenance. There might even be restrictions on where you can drive to.

Re:Hence why UEFI should be dismissed (0)

Anonymous Coward | about a year ago | (#44465019)

Dude, go to a fucking car dealer. Odds are you can find many vehicles with a push-button to start, that notched metal key you're so used to using? Has effectively been replaced with a chip instead.

The only reason they still put them in there is because of old fogies who think it's not going to work without them. They could just disconnect the ignition and 90% of them would never know.

Re:Hence why UEFI should be dismissed (1)

BitZtream (692029) | about a year ago | (#44465085)

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:Hence why UEFI should be dismissed (1)

Teun (17872) | about a year ago | (#44465325)

You can simply choose not to buy a Secure Boot implementation etc.

He said simply...

Re:Hence why UEFI should be dismissed (1)

sjames (1099) | about a year ago | (#44466055)

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 (2)

Billly Gates (198444) | about a year ago | (#44464973)

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 the SOYO boards 10 years ago which you had to disable power management before they even booted? What about the 10 year old Dell machines which put everything in IRQ 11? Want to upgrade your video card? Nope conflicts and BSOD. OF course slashdotters blamed XP, but investigation showed the IRQ conflicts were caused by crappy ACPI.

The list goes on and on.

EFI was supposed to fix this and use firmware like everything else modern. I like the secure boot idea and wish you could change the keys so you can sign any OS with a C.A.? Just put in a jumper or a master password. I like the idea of TPM for encryption as well. UEFI was supposed to replace the archaic ancient BIOS. Not supplement it and have MS be the gatekeeper.

To me perhaps a new UEFI where these issues are addressed and intel could perhaps provide a Windows 7 driver too as many of us and corps who need Windows God forbid wont touch Windows 8 or anything else and would like these features.

Linux as a result would be less buggy if everyone played by the same standards.

Re:I favor UEFI (1)

chill (34294) | about a year ago | (#44465523)

Amen

Re:I favor UEFI (1)

makomk (752139) | about a year ago | (#44467195)

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:Hence why UEFI should be dismissed (1)

BitZtream (692029) | about a year ago | (#44465047)

... 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 (0)

Anonymous Coward | about a year ago | (#44465149)

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*.

Re: Hence why UEFI should be dismissed (1)

segin (883667) | about a year ago | (#44465481)

Obviously you have very little clue how System Management Mode works on the 80386 and all successors. It's like a Ring -1, BIOSes can use it to interject into a fully running protected mode OS (e.g. translating USB keyboards and mice to appear as PS/2 devices for older OSes or smaller ones with nonexistent USB drivers) Compile a Linux kernel without any USB support. Plug in a USB keyboard. Enable "legacy USB" in your BIOS. Boot Linux. Watch your keyboard work without absolutely any USB (host) drivers loaded. Why? Because the BIOS, running in system Management Mode, runs it's own USB stack until a OS takes over (if ever), translating USB HID events to PS/2 mouse and AT keyboard events, which it injects into the running OS (or the BIOS's own PS/2 subsystem, if a real-mode OS that uses BIOS input services is running)

Re:Hence why UEFI should be dismissed (1)

Billly Gates (198444) | about a year ago | (#44465847)

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 Linux can boot properly and not have a half dozen implementations like the bios has. EFI is at least a documented standards. The bios is not and ACPI is really a guideline than a practice.

Re:Hence why UEFI should be dismissed (1)

RyuuzakiTetsuya (195424) | about a year ago | (#44465469)

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:Hence why UEFI should be dismissed (1)

ikhider (2837593) | about a year ago | (#44467231)

It's an attempt to block Linux/BSD/whatever.

Re:Hence why UEFI should be dismissed (1)

tlhIngan (30335) | about a year ago | (#44468435)

Hence why UEFI should be dismissed. If it's useless, just don't implement it, it's cheaper...

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 advantages over BIOS. For starters, it gets rid of TON of legacy crap - like 512 byte boot sectors, partition loaders, etc. GRUB has plenty of stage loaders just to load Linux because of BIOS. A modern UEFI loader is a single file executed by UEFI. Likewise, the ROMs that handle networking, display and such have a better interface through a well defined UEFI extension interface.

Of course, you probably meant UEFI Secure Boot, Which is separate from UEFI and only in very new PCs. But most PCs running today run UEFI. Linux has been supporting UEFI boot for a while too.

Re:Hence why UEFI should be dismissed (1)

gigaherz (2653757) | about a year ago | (#44468949)

UEFI is a better boot method than the old 16bit BIOS. PLEASE people stop hating on UEFI when it's just Secure Boot that you dislike.

Re: Hence why UEFI should be dismissed (0)

Anonymous Coward | about a year ago | (#44470525)

It was a dumb idea to begin with...

evden eve nakliyat istanbul (-1)

Anonymous Coward | about a year ago | (#44464653)

evden eve nakliyat istanbul [evdeneve-n...tanbul.com] firmalar inaat sektöründe uygun fiyat kaliteli hizmet tamaclk sunan sosyal ulamdr Her zaman güvenilir haritalar gezip dolaarak 7/24 bize ulaabilirsiniz.Sizda ayrcalklardan yararlanp deerlendirmek için frsatlara katln.

Bad implementations of security are vulnerable (2)

msobkow (48369) | about a year ago | (#44464685)

Film at 11.

Verification (1)

bunratty (545641) | about a year ago | (#44464769)

"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 you cannot prove a non-trivial program is correct simply by testing it on enough inputs.

I can't install Linux on a UEFI machine? (0)

Anonymous Coward | about a year ago | (#44464811)

Does this mean I can't install Linux or Windows 7 on a UEFI Secure Boot machine? (Newbie here)

Re:I can't install Linux on a UEFI machine? (2)

bill_mcgonigle (4333) | about a year ago | (#44464871)

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 to verifiable boots, which is a good thing, and Microsoft's spec is supposed to allow people to install their own keys, but I've read that some UEFI implementations don't do that right (more coding mistakes, I'd assume).

Re:I can't install Linux on a UEFI machine? (1)

blueg3 (192743) | about a year ago | (#44464959)

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.

Re: I can't install Linux on a UEFI machine? (0)

Anonymous Coward | about a year ago | (#44465055)

BIOS is nothing new. Almost all enterprise gear and most all consumer gear don't have the problems you're referring to. Like your parent said, a memory restriction for a dom is a kick in the pants after months of planning and implementation.

And then comes a fix right? Oh, you can't. None from vendor, and no software workaround, since it's a sw limitation on hardware resources.

It is clear as day how UEFI is being improperly supported in article, in 2nd parent above. Vendors lack of due diligence resulting in whatever intended security UEFI was supposed to provide, moot.

Required in Windows 8; forbidden in Windows RT (4, Interesting)

tepples (727027) | about a year ago | (#44465193)

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? (1)

Joe_Dragon (2206452) | about a year ago | (#44465069)

Do tell who made made this piece of shit.

Re:I can't install Linux on a UEFI machine? (1)

Balinares (316703) | about a year ago | (#44465561)

>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 are in development. The interesting thing about UEFI is that it comes with an extensive API, and can be configured from inside the currently running OS (check out efibootmgr on Linux for instance). When the dust has settled, installing and launching Linux will probably not be so vastly different from right now. Time will tell.

Re:I can't install Linux on a UEFI machine? (1)

Billly Gates (198444) | about a year ago | (#44464991)

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:I can't install Linux on a UEFI machine? (1)

AdamWill (604569) | about a year ago | (#44465555)

Then set up another CA. Microsoft isn't stopping anyone from doing it.

Re:I can't install Linux on a UEFI machine? (1)

Billly Gates (198444) | about a year ago | (#44465701)

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:I can't install Linux on a UEFI machine? (1)

AdamWill (604569) | about a year ago | (#44468135)

"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 chain. It does not say anything at all about who should issue keys or which particular keys any given firmware implementation should trust.

Re:I can't install Linux on a UEFI machine? (1)

kermidge (2221646) | about a year ago | (#44471051)

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 implementations of open specs.

Of course, even if OEMs do everything correctly there will still be plenty of end-users who'll screw up. At least that part will never change. What Descartes really said was, "I fuck up, therefore I'm human." but his editor made him change it.

Re:I can't install Linux on a UEFI machine? (1)

AdamWill (604569) | about a year ago | (#44479899)

"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 that there is no reason Microsoft has to be the only entity that does this; not written in the SB spec, not written in the Microsoft OEM requirements, not written anywhere. It would be entirely feasible for someone else to set up as a 'top level CA' for SB by convincing hardware vendors to trust their key, and then selling subkeys, the way Microsoft does. The fact is that nobody has done this, but there's nothing in particular preventing it.

Re:I can't install Linux on a UEFI machine? (1)

kermidge (2221646) | about a year ago | (#44483371)

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:I can't install Linux on a UEFI machine? (1)

AdamWill (604569) | about a year ago | (#44492887)

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 be given access to it.

It's a bit early to tell how this is working out in practice, so far. We are, of course, dealing with firmware engineers, who write bugs into their code just for the larks, and never show up at work without a crack pipe in each hand. It's a bit hard to tell what's people being confused about the specs, what's a bug, what's typical firmware crappiness, and what if anything is an Evil Microsoft Conspiracy...

Re:I can't install Linux on a UEFI machine? (1)

kermidge (2221646) | about a year ago | (#44521989)

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:I can't install Linux on a UEFI machine? (1)

thunderclap (972782) | about a year ago | (#44465017)

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

Confused again, eh Unknown Lamer? (0)

Anonymous Coward | about a year ago | (#44464929)

"Of course, a hardware security system that is too complex to verify seems like a fatal flaw."

The reality is that the effort is too much bother for the cost-cutting PHB, it's not that it can't be done, it's that they won't bother to do it.

It's no different than a vault door that somebody won't bother to lock and keep the key to enter secure. There is no implementation, hardware or software, that is so secure, it can protect you from yourself. OpenBSD, SeLinux, TrueCrypt, they can't keep you from putting your root password on a Post-It note stuck to the side of your monitor.

Similarly, nothing can stop a manufacturer from completely fucking up their hardware security, as any number of phone users have learned.

We need another layer of bootkit protection! (1)

GameboyRMH (1153867) | about a year ago | (#44465027)

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 (1)

qualico (731143) | about a year ago | (#44465143)

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:UEFI greatly increases comlpexity (1)

Billly Gates (198444) | about a year ago | (#44465909)

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 after hibernate in Linux), or having everything only go to IRQ 11 and cause conflicts and BSOD on gaming cards (Also dells made 11 years ago), which are all thanks to the bios.

Do we really need the bios anymore? I hate them as they cause bugs in Windows too and just Linux as they are soo bloated with 30 years worth of ancient stuff with many patches.

UEFI will hinder my testing of embedded (2)

michaelmalak (91262) | about a year ago | (#44465363)

In my blog [blogspot.com] , I describe my use of BootIt Bare Metal [terabyteunlimited.com] to rapidly test installs of "semi-embedded" software I write that involve wrapping third-party installs of drivers as sub-installs. This will work only as long as BIOS's and Microsoft continue to support "legacy mode". I'm just hoping that the scientific & embedded world finishes moving to Linux before "legacy mode" disappears.

Right. (1)

Rhywden (1940872) | about a year ago | (#44465423)

"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 (1)

davidwr (791652) | about a year ago | (#44467649)

You get to pick 2 ... on a good day.

What is the purpose of UEFI? (0)

Anonymous Coward | about a year ago | (#44467679)

I don't get any of it. Why does UEFI even exist?

I've never understood why people haven't implemented something lean and clean like OpenBoot/OpenFrimware on x86. Yeah, I know there are working implementations out there, but it's not a standardized thing so it doesn't really matter. So instead of having a nice firmware environment that is designed to boot the friggin' OS and get the hell out of the way, we've got this fucking monster of a firmware called UEFI that is essentially a pile of garbage with so much extraneous crap bolted on that it is frankly quite amazing.

Why? Is this the best that we can do these days? I mean, seriously, why the hell do people put up with this shit? Why the hell hasn't Microsoft been sued for antitrust again or something by requiring this rubbish on all the new computer?

What boggles my mind is that it seems totally unnecessary. We should have a totally barebones firmware designed for booting things off media, and then an optional way to include stable storage on the motherboard for all the crap people might not want by default. Like an SD card, or hell- even a USB port. Lots of servers have internal USB ports that you can jam a key into to boot into a hypervisor or some other embedded OS. Why can't all the stupid Microsoft-centric bits reside on a USB key sticking out of the motherboard? Then if I don't want them, I don't need their "boot key" installed on the internal USB port.

Re:What is the purpose of UEFI? (0)

Anonymous Coward | about a year ago | (#44468883)

I don't get any of it. Why does UEFI even exist?

Because BIOS sucks. It's a 16-bit relic carried over from the original IBM PC days that can't access anything more than 1MB of addressable space. It is incapable of doing things like initializing multiple devices at the same time, which makes booting very slow. It is x86 specific, meaning it won't work on Alpha, ARM, Itanium, or any other hardware platform. There are a few dozen other reasons as well, but you would be better served by google than me iterating them all.

I've never understood why people haven't implemented something lean and clean like OpenBoot/OpenFrimware on x86.

Why is OpenBoot/OpenFirmware better than UEFI? Both of those are untested an unsupported while tens of millions of devices are UEFI today, and have been working for the past 12+ years.

Yeah, I know there are working implementations out there, but it's not a standardized thing so it doesn't really matter.

What do you mean it's not a standardized thing? Of course it is. http://uefi.org/ [uefi.org]

So instead of having a nice firmware environment that is designed to boot the friggin' OS and get the hell out of the way, we've got this fucking monster of a firmware called UEFI that is essentially a pile of garbage with so much extraneous crap bolted on that it is frankly quite amazing. ... We should have a totally barebones firmware designed for booting things off media, and then an optional way to include stable storage on the motherboard for all the crap people might not want by default. Like an SD card, or hell- even a USB port. Lots of servers have internal USB ports that you can jam a key into to boot into a hypervisor or some other embedded OS.

Because people don't want barebones systems. They want to be able to do things like boot directly from CD/DVD/USB/SCSI. They want USB 2/3 drives to work and be bootable. Of course, all those things aren't "barebones", now are they? Barebones would mean it does the very basic minimum required by the majority of users. So it'll only boot if you have an NVidia card, using a PS/2 keyboard and mouse, off a Why the hell hasn't Microsoft been sued for antitrust again or something by requiring this rubbish on all the new computer?

Well for starters because Microsoft didn't write the UEFI standard. It was originally developed by Intel as the EFI standard, and then inherited by the UEFI group, which is made up of 11 different companies.

What boggles my mind is that it seems totally unnecessary. Why can't all the stupid Microsoft-centric bits reside on a USB key sticking out of the motherboard? Then if I don't want them, I don't need their "boot key" installed on the internal USB port.

There aren't any real "Microsoft-centric bits" inside UEFI. Some/many/most motherboard manufacturers include the 16? byte "key" from Microsoft so that they vast majority of users don't need to type it in to be able to enable Secure Boot on their system. You can delete this "HUGE" Microsoft-centric bit if you want to. You can disable Secure Boot if you want to. You can install any (or multiple) keys from anywhere (including yourself) if you want to. Now while I haven't tested every motherboard manufacturer out there, I can say for sure that these are all options on my own motherboard (ASUS Sabertooth X79), and I've never run into any UEFI motherboard in which these were not options.

Re:What is the purpose of UEFI? (1)

kermidge (2221646) | about a year ago | (#44471115)

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 (1)

Антон Кочков (3008017) | about a year ago | (#44472725)

So, using coreboot should help, by preventing security by obscurity. It have a lot of benefits [coreboot.org] : open source, small size, fast boot (while UEFI just a whole operating system, though without multithreading) and so on... Also it should help prevent some security problems [coreboot.org] of proprietary UEFI/BIOSes.

flawed but successful (1)

cas2000 (148703) | about a year ago | (#44481951)

Of course, a hardware security system that is too complex to verify seems like a fatal flaw.

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 (1)

jraff2 (2828801) | about a year ago | (#44497959)

Does anyone believe this garbage?!?!

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?