EFI and Linux: the future is here, and it's awful.

[GreyGeek]

Yes, I hear scary things about your roads and bridges. But at least your power grid outages are due to serious weather, not due to the national power monopoly having neglected to keep sufficient reserves of coal or to maintain power stations (to make their end of year figures look good so they get fat bonuses).

No problems with coal supplies, but our nuclear power plant owners have turned the NRC into their personal lawn jocky so that any requests they ask for are rubber stamped. We had TWO nuclear reactors in serious trouble here in Nebraska and only good fortune prevented a meltdown.
http://www.nonuclear.net/wealmostlostohio.htm
http://healthvermont.gov/enviro/rad/...hive_2010.aspx
https://integritythatworks.wordpress...aking-tritium/
http://www.riverkeeper.org/news-even...mer-explosion/
https://www.nytimes.com/2009/05/02/n...pagewanted=all

Most nuclear plants are 30 or more years old, were built by the lowest bidder, and are maintained by managers whose attitude seems to be pollyanna at best, while they cut corners to maximize profits.

[cavedweller]

To be honest on cell situation, I have an Iphone 4s because my company provides it and the data and texting packages that go with it along with a MiFi access point so if I am mobile in the field I can still communicate and work. My housing comes with all utilities, cable tv and broadband included in the rent. My wifes cell is a non contract pay as you go phone with text and mobile internet. It was cheaper for us to do it that way than to get stuck in a contract.

[tek_heretik]

This is insane and illegal, a software company has no business dictating to hardware makers, I smell a class action lawsuit in the works, if I have to start it myself.

[dequire]

Linus himself chimes in....

http://www.linuxtoday.com/infrastruc...efi-sucks.html

[ardvark71]

Yes, I hear scary things about your roads and bridges.

Hi...

That really depends on the state...some are better than others. Here in Oregon, they are in the process (and have been for several years) of reconstructing bridges to make them more earthquake resistant. :neutral:

Regards...

[GreyGeek]

That LinuxToday story is just hijacking a G+ thread posted by Linux.

Matthew Garrett had some things to say about EUFI, which I posted in a previous thread by Steve Riley, but it is relevant to this thread as well.

[SteveRiley]

So I had a chat with a buddy at work today (actually, we're at Interop in Las Vegas, but it's still work, heh). The one thing that makes virtualization kind of suck is the hypervisor. It adds an abstraction layer that affects VM performance, it's an attractive attack target, and it provides no real value. What if we could make the hypervisor go away and let hardware handle all the virtualization?

We're already most of the way there: VT-x and AMD-V virtualize the processor, VT-d and AMD-Vi virtualize the I/O, VT-c virtualizes the network, and IOV is working on a spec for virtualizing PCI-E. I'd be a whole lot more comfortable with hardware handling all the virtualization and thus eliminate the need for a trusted "parent" OS. In BIOS-based machines, this is impossible. With UEFI, this is absolutely possible.

Is UEFI perfect? Of course not. It needs work, and it would surely benefit from oversight by a non-aligned standards organization. But is it universally bad? Not at all. BIOS has outlived its usefulness. Let's move on.

[GreyGeek]

The only drawback to EUFI is the necessary cleanup of the code. Who's going to take responsibility for that? Most vendors will tweak their own little parts, build their little lock-in island and ignore the rest, leaving a messy collection of bugs, holes and such that bad guys will just love. Although EUFI is open source, how many OEMs would burn a copy of a universal version onto their firmware?

From a Linux kernel developer standpoint the EUFI introduces yet another area of unnecessary complexity which isn't well documented and would require them to reverse engineer every platform that uses it. Some OEM release dozens of versions of their hardware and I doubt that they would burn the exact same EUFI onto each of them. It would be worse than the video driver nightmares because there are a lot more combinations of HD + EUFI.

[SteveRiley]

Your criticisms are valid. Fortuntately, I think each one of them is also solvable. A possible approach is for virtualization vendors to do the work: after all, it isn't the boring hypervisors from VMware, Citrix, Oracle, KVM, or even Microsoft that make their various virtualization approaches attractive. It's the orchestration and management layers that ride atop their platforms. Consider vMotion, for example. Done right, it's really quite cool. Nothing about vMotion necessarily requires the VMware hypervisor.

Hypervisors don't really create much lock-in anymore either. Since so many VM-to-VM convsersion tools exist, someone who's decided they hate Xen can convert to something else relatively painlessly. So perhaps eliminating the hypervisor might be just what UEFI needs as a motivation to get the bugs fixed and the documentation improved.

(BTW, I can't take credit for this idea. It's been floating around the virtualization community for a little while now.)

[GreyGeek]

Interesting.

Just perhaps the FOSS community might take the UEFI source, trim the less useful parts, clean it up, and make it available to burn into firmware that can be used to replace proprietary firmware on PCs & laptops, etc..., so that the Linux kernel can communicate directly with it.

[tek_heretik]

Interesting.

Just perhaps the FOSS community might take the UEFI source, trim the less useful parts, clean it up, and make it available to burn into firmware that can be used to replace proprietary firmware on PCs & laptops, etc..., so that the Linux kernel can communicate directly with it.

Good idea but sad that we may have to eventually 'hack' hardware just to be able to run our favourite OS.

[SteveRiley]

Good idea but sad that we may have to eventually 'hack' hardware just to be able to run our favourite OS.

Ah, but it actually isn't hacking hardware. UEFI is all software, which is one of the aspects that make it better than BIOS. Jerry's idea is quite valid: I'd love to see a UEFI purged of the secure boot mechansim, for example. From what I understand so far, this is within the realm of possibility: download the source code, remove the undesired modules, compile, then flash.

To continue the virtualization idea, remember what the UEFI loader does:

1. Find the first FAT16/FAT32 partition on the first drive
2. Look inside the \\EFI directory
3. Present a menu of available operating system boot loaders
4. Begin executing the code in the selected boot loader
5. Get out of the way

Existing virtualization technologies already partition the CPU, memory, and I/O. We just need an appropriate extension to UEFI that allows it to load more than one operating system boot loader, each OS into its own memory partition.