Slashdot Mirror

UEFI: the only thing imaginable that could be worse than BIOS. Now, every computer has a shitty DOS-class OS burned into the firmware, which is permanently resident, and the perfect platform for back doors and spyware. That is on top of the IME, which reduces trust even further. Intel x86 considered harmful paints a vivid and damning picture of the modern x86 platform.

Any bootstrap mechanism should be simple and transparent, and leave the owner with full control of the machine. CoreBoot is a good starting point. Replacing x86 is a good next step, since Intel refuses to document the platform, and requires binary blobs to boot the platform.

There are worrying efforts which may also infect RISC-V platforms with UEFI and "secure" enclaves. It is ironic that open hardware efforts could help accelerate locked-down computing, if vendors widely adopt these user-hostile technologies.

CoreBoot has its place but it does not natively provide the security of the UEFI specification and also does not handle all of the potential use cases that the UEFI specification does as well. And how many exploits have you seen recently that revolve around issues in the firmware and not issues in the secure processor? I can tell you right now that most computers that have shipped in the last year or two, while potentially containing exploitable flaws, have generally not had any issue that allows an attacker to compromise the flash part unless they exploited a security issue in a BMC or through a secure processor such as ME or PSP.

UEFI: the only thing imaginable that could be worse than BIOS. Now, every computer has a shitty DOS-class OS burned into the firmware, which is permanently resident, and the perfect platform for back doors and spyware. That is on top of the IME, which reduces trust even further. Intel x86 considered harmful paints a vivid and damning picture of the modern x86 platform.

Any bootstrap mechanism should be simple and transparent, and leave the owner with full control of the machine. CoreBoot is a good starting point. Replacing x86 is a good next step, since Intel refuses to document the platform, and requires binary blobs to boot the platform.

There are worrying efforts which may also infect RISC-V platforms with UEFI and "secure" enclaves. It is ironic that open hardware efforts could help accelerate locked-down computing, if vendors widely adopt these user-hostile technologies.

ArgoUML

ArgoUML is the leading open source UML modeling tool and includes support for all standard UML 1.4 diagrams. It runs on any Java platform and is available in ten languages. See the feature list for more details.

Bongo

The Bongo Project is creating fun and simple mail, calendaring and contacts software: on top of a standards-based server stack; we're innovating fresh and interesting web user interfaces for managing personal communications. Bongo is providing an entirely free software solution which is less concerned with the corporate mail scenario and much more focused on how people want to organize their lives.

Boost

Boost provides free peer-reviewed portable C++ source libraries.

Boost emphasizes libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use.

Boost aims to establish “existing practice” and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2.

Bro Network Security Monitor

Bro provides a comprehensive platform for network traffic analysis, with a particular focus on semantic security monitoring at scale. While often compared to classic intrusion detection/prevention systems, Bro takes a quite different approach by providing users with a flexible framework that facilitates customized, in-depth monitoring far beyond the capabilities of traditional systems. With initial versions in operational deployment during the mid '90s already, Bro finds itself grounded in more than 20 years of research.

Buildbot

Buildbot is a freely-licensed framework which enables software developers to automate software build, test, and release processes for their software projects. First released in 2003, Buildbot is used by leading software projects around the world to automate all aspects of their software development cycle.

BusyBox

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

Clojars

Clojars is a community-maintained repository for free and open source libraries written in the Clojure programming language. Clojars emphasizes ease of use, publishing library packages that are simple to use with build automation tools.

coreboot

coreboot is an extended firmware platform that delivers light

Regardless, the government will just have keyloggers built into the BIOS. The manufacturers are the weak link here.

Keyloggers are a well-known problem -- and one for which security solutions are designed to mitigate. U2F was designed to be secure with a keylogger installed (because spyware is a thing). There are completely open, easily manufactured designs of U2F keys.

GPG cards similarly have an open design, and are designed such that the keys can't be recovered from the device -- and the critical decryption is done on the GPG card.

There's also Coreboot, Libreboot, and OpenFirmware before that -- all open source BIOSes you can audit and compile yourself.

Electronics hobbyists design entire computers -- from PC board design and manufacture (at home) all the way to working Linux computers with internet access. Completely from scratch.

The reality is that the skills and tools to bypass such spying is common, widespread, and well published. Many who have the skills are thrilled when somebody shows an interest in their hobby, and eagerly assist anyone who asks.

That's not idiocy, that's abuse.

I'm surprised nobody's come up with a fix for that yet. Wait, maybe someone has.

Coreboot supports it: https://www.coreboot.org/Board...

Doesn't seem too bad, similar to the X200 in terms of there being binary blog microcode and the ME. Maybe it's the GPU.

This has nothing to do with AMD

Even more so, as AMD doesn't use 28nm process anymore, neither on GPU (14nm FinFet), nor CPU (also 14 nm), whereas the chipset is still done with a coarser process AMD 990 (65 nm).

Nvidia also doesn't use anymore on their GPU (16nm).

Seems that 28nm was used back in 2010~2011 products.

So this stolen technology won't suddenly enable China to produce AMD/Nvidia GPU clones.

On then other hand, China's own home made Loongson CPU, is currently at 65nm, but some models are scaled down to 28nm (the Longsoon 3B).
So this is definitely going to help china produce their own CPUs locally, without needing to rely on some external 28nm-capable fab (currently Loongson are built by STMicroelectronics).

By adding 28nm capability to its portfolio, Huali Microelectronics would be in a position to offer to manufacture loongson locally - probably a worthy contract.

The Coreboot people have been trying to work out how to deal with this stuff for a long time. See https://www.coreboot.org/Intel.... They're trying to work out how to disable it, but progress is not that good.

Wiping the firmware and replacing it with coreboot would help too (assuming coreboot ever gets useful, widespread hardware support).

Coreboot "is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems.</marketing>

coreboot (formerly known as LinuxBIOS) is a free software project, aimed at replacing the proprietary BIOS firmware found in most computers with a lightweight system designed to perform only the minimum number of tasks necessary to load and run a modern 32-bit or 64-bit operating system. - https://en.wikipedia.org/wiki/Coreboot

It is true that the kernel is expected to load and run the ACPI bytecode in a trusted context... but your assumption that the BIOS is gone after the OS bootloader runs is inaccurate. SMM keeps BIOS code code resident forever and running at a higher privilege level than your OS kernel. And its impossible for your kernel to see what SMM is doing unlike ACPI which is pretty easy to inspect,

Your BIOS already owns the platform and getting rid of ACPI won't change that, it will just make it more difficult to firmware engineers (like me) to support all OSes with 1 firmware image.

I agree that ACPI sucks in a lot of ways, but you must admit that there is something to be said for a standard that has enabled WinXP (10+ year old OS) and brand new stuff like Win8.1 and all the countless Linux releases in between to run on practically any PC regardless of it being brand new or 10 years old.

IMO the trend towards having special firmware for each OS is disturbing and limits the universal and reusable PC. A lot of this is being driven by Google and thier insistence that Chrome OS systems be shipped without Legacy BIOS or UEFI support (locked down coreboot that only accepts OSes signed by Google unless run in "developer mode", btw even in developer mode you can't install a new coreboot payload to enable UEFI or legacy BIOS boot).

I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.

Or; you could write a FOSS module interlinked with ACPI to coreboot and then everything would be free and you would have the ACPI you wanted. You would probably even find that the community would fix the bugs in the software you wrote for free and you would sell extra hardware.

The thing is, that we want the full source to every bit. Anything less and the security risk is just too great.

And you have compiled your operating system yourself with a safe bootstrap compiler after reading every line of code? Doubtful but you might be one of the few

Escaping proprietary firmware.... http://www.coreboot.org/Welcom...

I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.

Or; you could write a FOSS module interlinked with ACPI to coreboot and then everything would be free and you would have the ACPI you wanted. You would probably even find that the community would fix the bugs in the software you wrote for free and you would sell extra hardware.

The thing is, that we want the full source to every bit. Anything less and the security risk is just too great.

Obviously trolling, but kind of an interesting question as the hardware isn't bad. I don't know why anyone would buy it with the intention of windows-izing it, but maybe the build quality is better than what the send windows in? Any case there are a million reasons for doing anything.

http://windows.microsoft.com/e...

Only 32 bit windows would fit, due to the 16 GB of storage.

Also not sure if the open source Coreboot will work with windows 8.1. You'd need to install seabios first, that's supposed to work for earlier versions of windows. Not sure about 8.

http://www.coreboot.org/SeaBIO...

However, your computer's BIOS, while in the past was usually impossible to change, can today be upgraded easily. That's why we now have Coreboot.

You make it sound as if technical difficulty in changing BIOS software is the issue, and I'm not sure if you realize that is not so. Software freedom has to do with an ethically based argument about giving permission to legally inspect, share, and modify published software (and, ideally, securing those freedoms to make sure nobody takes them away later). With BIOS code, as with any proprietary software, the distinction is not technical capability. The distinction centers on who is legally allowed to do what.

BIOSes prior to the arrival of Coreboot weren't all "impossible to change". BIOS distributors demonstrated that by making BIOS changes and distributing new proprietary BIOS software packages. Users were offered proprietary binaries that they could run—an ordinary installer program that allows non-technical users to easily install a new BIOS on the system.

But users were not given a copy of BIOS source code, users were not given permission to distribute the BIOS, and users were not given permission to modify the BIOS software. These users were subjugated to the BIOS developer's rule so long as they ran that BIOS code: users had no freedom to help themselves or their community. Coreboot changes this because Coreboot respects a user's software freedom, but the difference here is one of licensing. With Coreboot any user willing to learn what Coreboot does may inspect, share, and modify Coreboot; freedoms those same users don't have with a proprietary BIOS.

Most people who care a lot about software freedom draw the line at appliances, with an "appliance" being anything that can't get a firmware upgrade.

Currently, toasters can't get firmware upgrades (if they even have firmware) so nobody would care.

However, your computer's BIOS, while in the past was usually impossible to change, can today be upgraded easily. That's why we now have Coreboot.

I think you missed the "used to be" part of his comment. As in, what you're talking about is "now", and what he was talking about was "back then".

I fail to see why a BIOS would use the kernel of a general-purpose operating system.

Nevertheless that is what coreboot does. It used to be known as LinuxBIOS.

Unfortunately I don't have the skill set and there doesn't seem to be any other way to support them.

If you have a machine that supports it, Coreboot could be a very interesting solution.

Coreboot still applies microcode "binary blobs" from CPU vendors, so this still isn't truly free - http://www.coreboot.org/FAQ#Is_coreboot_applying_x86_microcode_patches.3F

you can revisit those those nostalgic 8MB and 4MB days again with the latest AMD chips as L2 cache. :)

just use a modifide version coreboot to bypass those silly POST tests and load to the CPU cache directly with Windows 3.11 :)

So, using coreboot should help, by preventing security by obscurity. It have a lot of benefits: 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 of proprietary UEFI/BIOSes.

So, using coreboot should help, by preventing security by obscurity. It have a lot of benefits: 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 of proprietary UEFI/BIOSes.

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! To see if my /boot/ configuration optimizations make improvements I have to measure my start-up time in Millseconds not Seconds!

I understand the software writers don't want to marginalize themselves in case servers adopt UEFI. However, there are zero security benefits of UEFI, versus booting part of your OS right from the BIOS/Firmware. It's up to the OS's bootloader to kick of an encryption chain after UEFI loads. So, put the damn bootloader in the firmware with Coreboot.

The way my setup works is that Coreboot has a bootstrap loader for my OS in firmware. The BIOS requrires a password to access it, and enable the flashing of firmware. Type password, "Enable Firmware Flash On Next Boot" option. No screwy hex code you're bound to mess up several times. My boot protocol uses public key crptography so that the custom multi-boot loader can handle any number of OS updates. The 2nd stage OS loader changes, it can include the signature of via key that's paired with the OS's 1st stage firmware boot loader. DONE. All we need is a standardized way for BIOS to flash a small part of the OS loader at OS install, and then any OS can be just as secure as secure boot, without ANY hierarchy of control -- The OS devs can own all the keys they use to secure and load their own OS. It's not like the chips don't have the memory now -- Shit, on new desktop systems the firmware has gaudy graphics, animations, and sounds -- The damn motherboard runs a stipped down Linux or BSD to prestent you the BIOS config options!

So, think about this. Coreboot + Key/Signing you already have to have in the OS loader is just as secure as UEFI, except there's no grand central Microsoft authority who says what OS can and can not install on the hardware, or to pressure hardware makers into bowing to the demands of the Windows requirements. If there is a bug in the BIOS or hardware that lets it rewrite firmware from software without permission, then it exploits UEFI or Coreboot equally -- How do you think UEFI is implemented -- IN FIRMWARE? Hell, I have the option with Coreboot to use UEFI boot if I want. However, I can also remove that shite, or even have the firmware setup legacy BIOS interrupt tables for booting old OS's like MSDOS, DR DOS, etc. Currently, I have my system config in my Coreboot, so it doesn't search for shit, just loads my OS and runs instantly at power up.
Coreboot w/ OS + SSD = Milliseconds to boot; Beat that, Security Theater Boot.

They should rename that shite, Microsoft Controlled Boot, because it is, for all intents and purposes. Stop and think. How can a sysop like me figure out a more flexible system that's just as secure as SecureBoot, more easy to use and maintain, and even adds security to tons of legacy x86 hardware -- Yet all those well paid folks who's only job was to engineer a secure boot standard "UEFI", came up with some restrictive shit that in effect gives Microsoft more control of the hardware and software arena? NO. ACTUALLY THINK. SEE?

I'm pretty sure it could be done using coreboot (formerly linuxbios). I don't think the code for it is written yet, of course, so yeah, there ain't one - yet.

Maybe because too many have turned it into as another poster put it "Hey lets bash" day although I would say it goes further than just bashing MSFT and UEFI but pretty much bashing anybody that doesn't follow the teaching of the great GNUcious himself RMS.

If you want people to care you have to stress the positives, we hear enough negative shit all damned day, last thing we want is to hear it on the weekend. What does open hardware do for ME, how does it help ME, what advantages are there to open hardware when its damned rare that my hardware actually last longer than the OS is supported?

Frankly every time I've seen an article on open hardware it quickly goes negative, it ends up being about "doom scenarios" like the way the GPL guys bash the BSD guys with these "ZOMFG they'll take ur stuff!" scenarios that never happen. I mean if all you care about is staying off of UEFI just buy a board off the coreboot list and call it a day. Pretty much all the AMD boards and chipsets are covered but support for Intel and Via is climbing so you have plenty of choices.

But if the ONLY positive you can come up with is hacking, something done by less than ohh..I'd say MAYBE 2% of the population if that? Well give it up Chuck, as the other 98% really don't give a shit. I mean why should they when the thing they bought does what they want or they wouldn't have bought the thing?

Put yourself in the role of selling this idea, I'm the public...what do you have to offer me? My netbook is 4 years old, my desktop is 3 years old and both do what I want, why would I risk possibly bricking the thing by hacking the hardware? And why would I care about hacking the Xbox? After all it plays games which is what we want it to do, what advantages does it give me?

Because frankly I think this whole thing isn't really well thought out, not if you expect the public to give a crap. After all they are more than happy to buy apple devices which are some of the most locked down, especially compared to Android, so you REALLY gotta sell this if you want anybody to care and from as few hits as this page got even geeks really don't give a shit.

Everything is wrong with secureboot.

Look, all we need is a simple BIOS option to that allows users to enable OS installs on next boot. When active it could flash part of the BIOS with the OS boot loader. FUCKING DONE. The OS will then be able to boot immediately, and can kick off it's own security chains to validate the rest of the kernel / etc. Use public key crypto in the "early kernel" loader and the existing firmware OS code can verify signatures of new kernel updates without being beholden to some 3rd party Dumbasses Like AMI. The users don't have to type in a fucking hex code (that they're sure to get wrong once or twice) just to boot a different OS. It has the same level of security as secure boot. It's SIMPLE. It already exists, and I actually do this already in my OS with core boot.

Secureboot is a rotting abortion and should be considered harmful.

Unlike most other software, replacing the firmware usually isn't even close to an option If you do some research before buying a new main board its a lot closer.

I runz the Linux!

I runz the Coreboot! ftfy

We have coreboot, but due to lack of support by a few major players, building a coreboot-capable machine takes more planning ahead of time than most people want to do, plus there's the whole "Flash your mobo" step, which turns a lot of people off. Plus, there is only one board supported that works with any kind of recent Intel CPU, unless you go for a server board.

I'm intending to purchase a motherboot that's supported by coreboot so I don't have to deal with UEFI

Why? What's wrong with UEFI that you need to replace it with coreboot (which just so happens to have a UEFI payload)

It's been almost 4 years since I built my last box. I'm planning on building another desktop this summer and would like to know who to avoid as I'm intending to purchase a motherboot that's supported by coreboot so I don't have to deal with UEFI. If there's a motherboard vendor doing evil stuff and they're listed I would like to avoid them if I can. Here's the link for supported motherboards: http://www.coreboot.org/Supported_Motherboards

No, you can put whatever OS you want on a Chromebook assuming, like has always been true, the OS supports the hardware.

Ubuntu being the only one to support it isn't Chromebook's fault. Go yell at to support it, or in the spirit of open source, add it yourself. There's nothing particularly special about Chromebook's BIOS.

Well, I guess that's not entirely true. The special thing is that it uses Coreboot and U-Boot - both of which are *OPEN SOURCE PROJECTS* ( http://www.coreboot.org/Welcome_to_coreboot and http://en.wikipedia.org/wiki/Das_U-Boot respectively).

And the people looking to take a windows PC and convert it to a linux pc... well they're will always be someone you can take it to to flash an open bios or otherwise 'unlock it'.

Or those people along with anyone else who actually cares about open hardware could just put their money where their mouths are and buy AMD who is switching to Coreboot which is a FOSS BIOS/UEFI replacement. After all no need to "flash an open BIOS" if you already have one.

Anyone with physical access can probably reset the BIOS password and turn off secure boot.

The point of secure boot is to make possible a chain of proof attesting that everything that gets loaded into ring0 has not been modified. Clearly if you can disable the chain of proof then you can disabled the chain of proof, but you cannot do so invisibly, which is the entire point of secure boot.

So, uh, wouldn't we just then perform a SHA512 hash of the dumped hibernation memory? A salted hash is good enough to detect tampering if you're not concerned about hiding the data in the dump. A loader would then perform the same salted hash of memory as it's loading it and abort if the resulting hash doesn't match the on-disk hash. Of course the same code signing chain technology Secure Boot employs can be used to sign the salt & hash to ensure the dump's integrity.

OK, here's the thing: Is there any kernel level exploit in the OS? If the answer is yes, then return oriented programming can be used to create malware that runs even when the code is signed and encrypted -- It'll just use the existing valid code of the system to create itself. You don't even need to know exactly what the encrypted code does, you just have to observe the state changes of the system and develop your malicious return oriented "op-codes" out of the places you can jump to. There's no need to even tamper with the boot sector because said malware can simply re-exploit the OS after it's booted up.

An OS has to create a trust chain to maintain it after control leaves secure boot -- Really, all we needed was the ability to flash the BIOS with the OS bootloader, and give people the option to "allow OS installs on next boot" in the boot options menu. Way fucking easier than performing some ceremonious mental masturbation encryption key entry in BIOS, that end users are BOUND to fuck up on the first try. Secure boot has no more security that putting the OS bootloader on the MOBO, and it's 100 times more complex.

"Make everything as simple as possible but not simpler." -Albert Einstein.
Secure Boot is Epic Fail on all fronts except for pushing MS's proprietary FAT file system into every OS on the planet. I won't use it, and consider UEFI harmful. Also CoreBoot Already Exists, so that's what I use even on x86 systems to boot instantly to Linux. You can mount your whole /boot/ on the MOBO if it's got enough space... Up and running in milliseconds. Screw security theater boot, there is really no valid "point" for it to exist.

Maybe we should only buy machines listed on coreboot.org

May I suggest this page http://www.coreboot.org/Supported_Motherboards

A supported motherboard can even run with an open source BIOS.

Pretty good bet, they'll be Linux compatible.

As far as I know, Coreboot (open source bios) comes close, but it does seem you are correct that it is a processor problem.

http://www.coreboot.org/Benefits

Chromebooks come with coreboot (formerly known as LinuxBIOS), it is not a traditional BIOS, nor UEFI. UEFI, at least on the machines I have tried it, is slow to boot !!!!!!. but your question still is valid. I don't know if the developer mode switch allows firmware modifications. I hope so

Coreboot requires a lot of work to get ported to a new motherboard. I'm trying to wrap my head around how to build and run it just for QEMU and am not getting very far. Keep in mind that Coreboot just sets up the hardware. You also need a payload to accomplish what the BIOS and/or EFI used to do. There is SeaBIOS that replaces the bios, OpenBIOS that provides a Sun-like OpenFirmware, and FILO which is sort of like LILO or Grub in firmware. An overarching deficiency though, is there is no built-in equivalent of the setup menu. I haven't yet figured out what the equivalent is.

Coreboot requires a lot of work to get ported to a new motherboard. I'm trying to wrap my head around how to build and run it just for QEMU and am not getting very far. Keep in mind that Coreboot just sets up the hardware. You also need a payload to accomplish what the BIOS and/or EFI used to do. There is SeaBIOS that replaces the bios, OpenBIOS that provides a Sun-like OpenFirmware, and FILO which is sort of like LILO or Grub in firmware. An overarching deficiency though, is there is no built-in equivalent of the setup menu. I haven't yet figured out what the equivalent is.

Coreboot requires a lot of work to get ported to a new motherboard. I'm trying to wrap my head around how to build and run it just for QEMU and am not getting very far. Keep in mind that Coreboot just sets up the hardware. You also need a payload to accomplish what the BIOS and/or EFI used to do. There is SeaBIOS that replaces the bios, OpenBIOS that provides a Sun-like OpenFirmware, and FILO which is sort of like LILO or Grub in firmware. An overarching deficiency though, is there is no built-in equivalent of the setup menu. I haven't yet figured out what the equivalent is.

So when you get your MB (made in China), with a BIOS apparently coded in a rural part of China (have you seen BIOS lately?), and find it doesn't let you disable it...

What, exactly, is your recourse?

Coreboot is the only answer, and that's not going to happen while Microsoft (and probably Apple as well) isn't bankrupt.

Then buy a different one? Good lord, how hard is that?

I think this was the original idea behind Coreboot.

So when you get your MB (made in China), with a BIOS apparently coded in a rural part of China (have you seen BIOS lately?), and find it doesn't let you disable it...

What, exactly, is your recourse?

Coreboot is the only answer, and that's not going to happen while Microsoft (and probably Apple as well) isn't bankrupt.

You, if OEM wanted to run coreboot, they could do it already, mainly because :
- they have the hardware specs ( heck, they are doing it )
- they have the engineers

In fact, if you take a look on the blog of coreboot, you can see stuff like this :
http://blogs.coreboot.org/blog/2011/05/06/amd-commits-to-coreboot/

What I really want, is something like http://www.eetasia.com/articleLogin.do?artId=8800626684&fromWhere=/ART_8800626684_1034362_NP_93053a1f.HTM&catId=1034362&newsType=NP&pageNo=null&encode=93053a1f

There are a number of efforts to boot up, and be on a working desktop in very few seconds. In fact, I plan on building my next desktop on a mainboard supported by Coreboot - http://www.coreboot.org/OpenBIOS With a custom BIOS, an SSD, and all the optimizations I can find for boot time in Linux, I should get 3 or 4 second boot times.

Instant on. I mean, even televisions are "instant on" these days. There aren't any tubes to warm up, or anything like that.

i expect this to be one more thing i either loathe or disable as a sysadmin. UEFI, welcome to the hallowed esteems of DRAC, BMC, IPMI, ACPI, and APMI.

Thankfully, those can mostly be ignored except ACPI. EFI in general certainly seems similar to ACPI in that it attempts to solve shortcomings of older systems in an unnecessarily complex way and is therefore doomed to be implemented incompletely and incorrectly. We certainly need something to replace the PC BIOS, but I'm not sure we need EFI. It would be awesome if all motherboard manufacturers and OEMs made Coreboot work on their systems. It can have payloads of Free and Open implementations of UEFI and PC BIOS as well as being able to boot Linux, Grub, and many other things directly. A board running Coreboot can boot just about anything much faster and more flexibly than any of the industry standard approaches.