How I (sort of) conquered UEFI

[jpenguin]

My computers have BIOS, but for the heck of it I created a ubuntu-64 guest in VB and turned on EFI- it wouldn't boot from any ISO (all the ISO's booted in the BIOS VM) except a Ubuntu 11.04 desktop ISO I had. That installed, but wouldn't boot...

[SteveRiley]

I created a ubuntu-64 guest in VB and turned on EFI- it wouldn't boot from any ISO (all the ISO's booted in the BIOS VM) except a Ubuntu 11.04 desktop ISO I had. That installed, but wouldn't boot...

Download the Ubuntu 12.04 alternate installer ISO. Run an advanced-mode command-line install. Do allow GRUB to be installed. If your experience turns out to be like mine, it'll work.

Of course, this is dependent on the quality of VirtualBox's UEFI emulation, which I haven't checked.

[SteveRiley]

Don't get me wrong, I'm with you on this.

Oh, I didn't think you were trying to argue

I'm not of the opinion that Microsoft has plans to stick it to Linux with their recent decisions.

Agreed. I generally try to avoid imputing evilness onto the actions of others. I have my doubts about whether Microsoft really feels the need to stamp out desktop Linux. Is it truly that much of a competitive threat? I think not.

Rather, I fear the whole industry is using the UEFI spec to achieve the same position as one sees on mobile devices - a "complete" system where you can only do a certain amount of things. My sister's laptop, an Asus, has UEFI. It's designed to run in legacy BIOS mode, but it doesn't boot from USB in such a configuration.

In its default configuration, UEFI presents a great deal of flexibility. Alas, this flexibility allows implementers the freedom to disable whatever elements they wish. That your sister's Asus won't boot from a USB stick in BIOS mode indicates Asus intentionally disabled that functionality.

not in the least because Linux users will be among the first to get into the habit of opening a shell in UEFI.

From what I understand so far, if secure-boot is enabled, it can prohibit booting the EFI Shell. If secure-boot is disabled, there's no other way to prevent someone skilled enough from booting the EFI Shell and regaining control. There's probably even a way to fix your sister's Asus so that BIOS mode permits booting from USB. I don't know enough yet to tell you where to look for that specific item, but if you have a free weekend coming up, you could always dive into Intel's published documentation

[lo_koraco]

When I install Precise on there, I'll go UEFI only for a test drive. She lives in another city, and I didn't have a lot of time to fiddle around with Natty. The point is, few regular users will know what to do with their systems. And since Asus did this on a laptop in the cheap range, I'm seeing an intention by the OEMs to disable (setting the system to go in BIOS compatibility mode and disabling booting from USB is the same as removing that feature as far as regular users go) functionality. I agree with you, UEFI presents a great deal of improvements, there's bound to be some bugs, but the real problem is how OEMs wanna exploit it, which seems to be dubious to say the least.

Linus and Garrett are Luddites, I'm not surprised they have their range of issues

[dibl]

Thanks for doing the work and posting this, Steve. I've been watching the advent of UEFI with a jaundiced eye -- glad I built my new desktop last fall and don't have to deal with it (yet). But of course one of these days we'll have to know this stuff, and more.

[jpenguin]

12.04a2 installed grub-efi & everything installed right, still wont boot. Must be VB's efi, I found this http://girlyngeek.blogspot.com/2011/...ade-retro.html

Download the Ubuntu 12.04 alternate installer ISO. Run an advanced-mode command-line install. Do allow GRUB to be installed. If your experience turns out to be like mine, it'll work.

Of course, this is dependent on the quality of VirtualBox's UEFI emulation, which I haven't checked.

[SteveRiley]

Later this evening I'll post a list of my X1's NVRAM variables so you can see what it looks like.

Here's the output of efibootmgr on my X1:

steve@x1:~$ sudo efibootmgr -v
BootCurrent: 0013
Timeout: 0 seconds
BootOrder: 0013,0006,0007,000A,0009,000B,000C,0008,000D
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash Screen
Boot0003  Startup Interrupt Menu
Boot0004  ME Configuration Menu
Boot0005  Rescue and Recovery
Boot0006* USB CD        030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0007* USB FDD       030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0008* ATA HDD2      030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f602
Boot0009* ATA HDD0      030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000A* USB HDD       030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot000B* PCI LAN       030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot000C* ATAPI CD1     030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35403
Boot000D* ATA HDD3      030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f603
Boot000E* IDER BOOT CDROM       ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot000F* IDER BOOT Floppy      ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0010* ATA HDD       030a2400d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f6
Boot0011* ATAPI CD:     030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354
Boot0012* PCI LAN       030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot0013* ubuntu        HD(1,28,100000,6ead9c9b-5ed2-46a0-80ad-e53905c57b4a)File(\EFI\ubuntu\grubx64.efi)

During installation, the setup scripts for grub-efi call efibootmgr to create the NVRAM variable for the operating system being installed. You can see the results in the list: Boot0013. Specifically, the command to create that was:

efibootmgr --create --disk /dev/sda --partition 1 --loader \\EFI\\ubuntu\\grubx64.efi --label ubuntu

So what's all that other stuff?

In the days of BIOS, remember how you could enter a setup menu and alter the ordered list of boot devices? And/or press a key during boot to temporarily choose another device? Well, you can do that in UEFI, too. But unlike BIOS, where that list of devices was something of a secret, in UEFI, the boot list is stored in the Boot Manager, which is a collection of variables in NVRAM. The Boot Manager contains pointers to:

• Elements of the UEFI itself
• Traditional boot devices
• UEFI-aware operating systems that are registered with UEFI

On my X1, variables 0000..0005 point to UEFI elements. Variables 0006..0012 point to boot devices. Variable 0013 points to GRUB.

Notice the asterisks. This symbolizes which devices and boot loaders the UEFI will scan for something it recognizes as bootable. The order of scanning is controlled by the variable BootOrder; note that 0013 is first in my list, so under normal conditions I don't see a boot menu. If I press [F12], the X1's temporary boot order list picker, I will see a list of all devices that were detected as containing something bootable. The UEFI elements themselves don't possess the boot search asterisk because these are useful only when you're in the UEFI setup menu, which I can launch if I press [F1] during boot.

Now here's another neat trick about UEFI. Since everything's a file, that means most items can be manipulated outside the setup menu. I can change the boot order in three places:

• The UEFI setup menu, which is expected -- this is how you do it in BIOS, too
• The EFI shell
• Using the efibootmgr command while the operating system is running

Various switches on the command line allow me to temporarily or permanently alter the boot order. I can also add and delete variables; deleting is permanent, undoable, and unguarded! See man efibootmgr for more information.

[silviucc]

GG, in al fairness, the fact that future ARM tablets with W8 on them will have Secure Boot enabled (and no way to disable it) is not of concern. MS does not have a monopoly in the tablet market. Apple and various vendors with Android products do, and they also lock their stuff.

While I have no doubt that machines from Dell, HP and others that want "MS Signature" will be lacking the option to turn off secure boot, general consumer mobos will not. There is no way in hell that Asus, Gigabyte, etc will not offer a way to disable Secure Boot.

[GreyGeek]

GG, in al fairness, the fact that future ARM tablets with W8 on them will have Secure Boot enabled (and no way to disable it) is not of concern. MS does not have a monopoly in the tablet market. Apple and various vendors with Android products do, and they also lock their stuff.

But, it does make it obvious that given the opportunity they will. Their history of doing so is well documented.

One can begin with Dr Dobbs Journal uncovering Microsoft's plans to destroy DRDOS, which was a much better DOS than MSDOS, by checking for the DOS when Win3 was being installed, and if found to cancel the install with the msg "Incompatible DOS". Dr. Dobbs replaced that code in the Win3 binary with NOPs and redid the install. Win3 ran better on DRDOS than it did on MSDOS. Like the UEFI, the only purpose of the code was to block a competitor. And yes, Linux IS a competitor to Microsoft. If they did not see Linux as such they wouldn't waste so much money and energy fighting it. They'd ignore it.

Since the DRDOS fiasco there has been James Plamondon's "Technical Evangelists" and their astroturfing, and a trail of dirty and/or illegal tricks right up to to OOXML ISO committee fiasco, the attempt to sell 235 IPs with instructions on how to sue Linux distro makers, the hijacking of OLPC and the European Future of Open Source document. The fact that Microsoft requires UEFI be turned on to obtain Win8 certification, and the PC OEMs cannot turn it off and risk losing the ad rebates from Microsoft (and hence their razor thin profits), pretty well makes it a high hurdle for Linux distro makers and users. VERY FEW Linux users have the technical skills Steve Riley demonstrated were necessary to install Linux. Matthew Garret, (or Linus himself), far from being "Luddites" as some claim, are working hard to to find ways to make the Linux kernel compatible with or able to penetrate the UEFI to enable a LiveCD boot and install of Linux. Add to this the fact that even IF they succeed for a specific set of hardware, there is no guarantee that the next version of that hardware will have not unannounced upgrades in hardware & firmware versions which would render past adjustments unworkable. This happens all the time for devices as simple as video and audio services. It is quite common for a PC OEM to switch internal devices and/or upgrade firmware version numbers without stating such changes on the documentation or specifications. For example, a friend of mine purchased a Gateway mpr675 laptop a year before. We installed Linux on it and it ran beautifully. A few months later I purchased the exact same model. The new release of PCLinuxOS ran on it beautifully, but when we tried to install it on his one year old Gateway it failed to drive the video or the wireless. The only changes we could see in the hardware were the version numbers on the chips changing from V1.0 to V1.1 and V1.3. So, the lack of a monopoly, as the past has proven, is no guarantee that Microsoft won't continue to try to slant the playing field in its favor by any means available to it, twisting law or lack of ethics not withstanding.

While I have no doubt that machines from Dell, HP and others that want "MS Signature" will be lacking the option to turn off secure boot, general consumer mobos will not. There is no way in hell that Asus, Gigabyte, etc will not offer a way to disable Secure Boot.

Again, that's like telling Linux users if they can't eat bread let them eat cake. How many general computer users do you know who have the technical skills to either replace a mobo or to build a PC from parts? So few, in fact, that if that were the only venue open to Linux users it would soon beome a nich hobby instead of what it has achieved today. Linux has risen from a 3% desktop market share in 2003 to a 12% market share in 2009, according to Ballmer himself. The extra percentages, above that which were forecast, were due to the appearance of the LiveCD, which enabled Joe and Sally Sixpack to merely boot the CD, answer a few questions and replace the pre-installed Windows with Linux, if they asked for a free CD from Canonical. Now that the free CDs have stopped, users have to download the ISO, check its md5sum both before and after the burn to make a LiveCD, then boot it. If their hardware doesn't boot from the CD they have to enter the BIOS and change the boot order to do so. Those are a LOT of technical hurdles to over come to install Linux, but a LOT of people were motivated to do it, and still are.

The growth of Linux on the desktop is continuing unabated, even though the PC market is not growing because a lot of new users are opting for smartphones instead of PCs and a lot of former PC users are switching to smartphones, some keeping their PCs, some not. Since the security of Windows is NOT enhanced after the boot process is over, one cannot claim that the UEFI is to improve Windows security, as some claim. It will still continue to be the major resident of massive multi-million zombie bot farms. IMO, and many others, the ONLY purpose for UEFI is to use hardware enforced certification to block Linux at all levels simultaneously.

Asus, Gigabyte and other PC hardware makers are corporate entities with one purpose: maximize profit. If most are dependent on Microsoft for their ad rebate money to make a profit, and they are, they will lock up Secure Boot in the blink of an eye, your assurances not withstanding.

[SteveRiley]

Lenovo issued a UEFI update for the X1. As you can probably imagine, neither of the available download formats are immediately useful for me. My choices:

* An executable that runs in Windows
* An ISO that you have to burn to a CD-ROM

The Windows version is obviously not helpful for me. But the ISO is truly silly -- there's no optical drive on this thing!

Ah, but surely you can mount it, right? Or open it in Ark, right? Wrong:


Looks like a broken ISO to me, being empty and all. So I head over to the Lenovo forum to inquire about my quandary. Turns out these ISOs contain some kind of hidden image not normally visible. One person explained that you can peek into the ISO with 7zip, and even showed a screen capture. Well, something is there, but certainly no new UEFI...the ISO is about 34 MB, but 7zip detects a measly 512-byte file:

steve@x1:~/Downloads$ 7z l 8muj10uc.iso 

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)

Listing archive: 8muj10uc.iso

--
Path = 8muj10uc.iso
Type = Iso
Created = 2011-11-11 16:22:00
Modified = 2011-11-11 16:22:00

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
                    .....          512          512  [BOOT]/Bootable_HardDisk.img
------------------- ----- ------------ ------------  ------------------------
                                   512          512  1 files, 0 folders

Why does Lenovo have to make this so frustrating?

Fortunately, someone else has navigated these troubled waters previously. A Perl script called geteltorito appears to be the only thing that can sort its way through the fog and properly extract the image. Once extracted, it was a cinch to dd the thing to a USB drive. It booted to FreeDOS, displayed a menu, nagged me to plug in the power cord, and finally updated the UEFI.

Curious to see whether anything new appeared in the setup menu, I pressed [F1] during boot. Nope, nothing new there; the update was really just a few bug fixes. However, it was interesting to see that the list of boot devices contained an additional item: Boot0013, the NVRAM entry for my Ubuntu installation:



Yeah, the more I futz with this stuff, the more I come to realize it's pretty cool. But like many of you, I worry that it will be abused.

[GreyGeek]

Did you try the mount command with the "loop" parameter?

[SteveRiley]

Still shows up empty. Apparently the whole thing is crammed into the El Torito boot portion of the ISO, which requires something that's aware of El Torito in order to extract the image. That Perl script is actually part of Debian's genisoimage utility.

[MoonRise]

Thanks Steve for the post. If I had a UEFI deviced I think I'd like to do the same. Alas I don't and time doesn't permit so I appreciate this post.

[SteveRiley]

Cool, I'm glad people have found this info useful.

Despite raising two teenagers, playing in three symphonic bands, and occasionally traveling for my job, I manage to find the time somewhere to dig into this stuff. Alas, some things I used to enjoy don't get the same attention now...

[GreyGeek]

Cool, I'm glad people have found this info useful.

That's why I think you should promote your OP to an Article, or at least pin it.

Despite raising two teenagers, playing in three symphonic bands, and occasionally traveling for my job, I manage to find the time somewhere to dig into this stuff. Alas, some things I used to enjoy don't get the same attention now...

Face it, you're getting too old to do levitation tricks with a mountain bike!