On 02/27/2013 04:20 AM, Paul Robert Marino wrote:
I have an X120e as well and simply changing the hard drive doesn't fix the eufi issue. the first answer to this string is correct with two cavorts RedHat got two signed certs one fro RHEL and the other for Fedora. apparently the process was a nightmare but they will work with secure boot. for that reason I run fedora as my primary os on my laptop and if i have to do any Scientific Linux testing I run it in a VM (and yes an AMD fusion chip can runs a single VM surprisingly well)..
We supply our customers with Linux and dual-boot systems, and recently have run headlong into the UEFI madness. Any new consumer-grade x86 system will have an escape key on boot that gets you into setup the same way old BIOS-based boards did (this can be tricky with keyboardless tablets -- sometimes a USB keyboard can work, sometimes its just plain random like pressing a volume button or something). The weird part with UEFI is that the key is hidden, non-standard between makers -- even different between board models, never announced on the boot screen, has an amazingly short activation window (usually 1 second), and (so far in our experience) never mentioned in any vendor documentation other than (occasionally) Toshiba laptop manuals. We've resorted to playing "F-key piano" within when testing new models. Silly, but it often works.
Within the UEFI setup there will be an option for enabling "UEFI" or "CRM" and changing the boot source order. "CRM" indicates a BIOS-style boot and works with anything BIOS booting did. UEFI is, of course, UEFI, and requires a key. There is supposedly a way to insert your own key into the UEFI registry so that you can sign your own bootloaders, but I've seen zero evidence of this myself.
Its almost like someone is trying to kill off the smaller OS and hardware vendors and make corporate IT into an Old Boys' club again -- but such a sweeping conspiracy would have raised an outcry somewhere...?
There is a silver lining. The board makers themselves are out to sell boards and laptops and tablets and can be reasoned with. My company is an extremely small player in the hardware field but we've had positive response from vendors when inquiring about having our own keys included on boards alongside Microsoft's when doing bulk orders. We haven't had to go that route yet so I'm unsure how much of a pain that would actually be to manage (doesn't appear much more difficult than managing repository keys though, for example), but this leaves the door open for even tiny computing companies and larger IT departments to arrange for their own "secure" boot keys to be pre-installed by the board manufacturers and not violate Microsoft's requirements, even on ARM. That said, since we don't do showroom marketing anyway neither we nor our suppliers have a need to put little "Windows8 Ready" stickers on anything they ship to us anyway.
From a security perspective it is important to note that physical access to a system still equates to compromise and UEFI can't do anything to prevent that. It is also interesting to note that as we've thought through security compromise based on the boot cycle, leaving the Windows key alongside our key leaves a door open for someone to write malware that is based on a valid version of Windows that runs the "real" system in a VM anyway, and there isn't a clean way out of that.
Blah blah blah. My point is that there is a possibility for OS suppliers/providers to provide their own UEFI keys because board makers are willing to play ball (so far). This does require, however, that at the smaller level OS and hardware vendors have to merge or coordinate somewhat in practice -- but as we've found over the last few years, when you do the software you start wanting to do the hardware, too, so it works out. The downside is that unless you're already established or have the investment backing required to maintain an entire OS yourself it will be pretty much impossible to start a non-Windows computing company from here on out
If we sensed much demand for consumer-end (as in, personal, not business) systems running $distro then we'd probably jump on the chance to run our own UEFI-based program -- but we're troubled by the idea that doing so would lock buyers of our hardware into $distro (or at least our bootloader, depending on how things were set up) the same way MS has done, and that isn't really something we see as a competitive advantage in a market niche loaded with hordes of people who want to/need to try out different things on their own. Tricky.
-z
