“Some of my recent time has been devoted to making our boot media more Mac friendly, which has entailed rather a lot of rebooting. This would have been fine, if tedious, except that some number of boots would fall over with either a clearly impossible kernel panic or userspace segfaulting in places that made no sense. Something was clearly wrong. Crashes that shouldn’t happen are generally an indication of memory corruption. The question is how that corruption is being triggered. Hunting that down wasn’t terribly easy.” Very interesting – and, unlike what the title suggest, not particularly related to the secure boot stuff.
The more I read about UEFI, the more it seems to be to BIOS features what ACPI is to APM and the MP specification.
-Take small specs that work reasonably well and are easy to understand
-Attempt to combine them together in a cohesive whole, adding some useful extra features in the way
-Pile layers of abstraction above layers of abstraction to glue together totally unrelated stuff. Be careful to make simple things so complicated that implementations WILL be buggy in this process.
-Ask OS kernels to execute random code at unknown memory-mapped addresses with maximum privilege, perfection being reached when they have to code a relatively complex interpreter for that purpose
-Make a lot of assumptions about said kernels, such as assuming a monolithic kernel architecture or a PE executable file format. After all, everyone uses Windows.
-Then proceed to describe every form of hardware or functionality known to man in the spec so that it gets thousands of pages long
-Above all, do not mandate hardware manufacturers to include any useful subset of the described functionality for compatibility with the spec, and do not sanction manufacturers which do not comply at all with the spec
-To complete your roaring rampage of destruction, deprecate any older spec in favor of the steaming pile of crap which you just unleashed on the computing world.
Edited 2012-03-18 21:37 UTC
– ???
– profit(?)
You’re right, I forgot this very important part
As a somewhat happy owner of an MBP laptop, used to run primarily windows, I feel the same pain that Matthew Garrett does – I only miss his fantastic skills to troubleshoot the problems.
The multiboot experience has been a hit and miss since day one. I keep an eye on Apples sw updates, and install any new firmware as soon as it is out, but I still have random bad things happening, such as:
. refit not usable because booting from it disables control of screen brightness
. sometimes coming off from sleep the keyboard is not responding (luckily plugging in an usb mouse, I can enter the password via onscreen keyboard and shutdown)
. sometimes the laptop does not sleep when the lid is closed. And if put in the bag while on, it risks melting down due to overheating
. when laptop goes to sleep because battery is low, it does not really hibernate. When turned on again, it resumes to the point of turning on the screen, then finally hibernates. It takes 30 secs for it to hibernate and come back, grr!
. touchpad driver just plain sucks. A cool one is available from a russian guy, but it’s not really open source (asks for money or reinstall every week!)
. battery does not last more than 3 hours, because no drivers are provided for windows to use the on-chip video card for maximum power saving
I managed to get windows installed with 2 partitions, and reserve space on disk for linux, only to find out that there is no triple-boot supported with bootcamp, and that the only way to get all the partitions I want on the disk is to have all OS boot via efi and not via bios. Except that I have to reinstall windows and am damn scared of testing linux bootloaders support for efi…
Maybe you should stick to running Mac OS X then, and simply run Windows and Linux in a VM (VirtualBox, Parallels etc).
I’m about to buy a MBP for the first time, and from all the information I read on the net, the above setup seems to be the safest (sane) choice. Saying that, I will probably try installing FreeBSD as a sole OS on my MBP t oo (simply for the ZFS support).
Every time there’s a major hardware foundation switch, this is expected to happen. Like ISA to PCI, PCI to AGP (for graphics) etc. The sad reality is that developers need to actually dig in to the UEFI standard and learn its innars, issues and limitations. You just can’t expect it to work seamlessly given the astounding changes done to the whole hardware and language.
UEFI is here to stay and hopefully everyone does their homework/provide feedback also to the developers so that in future versions the issues are take care of.
Not quite the same. Matthew Garrett *does* dig into the spec – indeed, he’s probably one of the most knowledgeable people you could find on the subject.
The problem is that UEFI implementations seem to be *very* flaky, and not very good at conforming to the specification. They work fine with the OS they were developed for (MacOS, mostly), but are a real pain as soon as you try doing something that the spec says should work, but which never got tested.
UEFI was actually developed for HP and their Itanium servers. I used it sparingly back in the early 2002s. I can confirm that it was a piece of absolute crap in its initial forms (it would lose saved settings for no apparent), but the one we have nowadays is absolutely awesome.
I wonder if this is just the EFI for that specific version or the mac or if it is the same across the board.
Unless they have the hardware to test it its a crapshoot.
The firmware activated the wifi (ostensibly to netboot) and left it DMA-ing into RAM? Peachy. Between this and SMM (thanks again, Intel) it will be impossible to remove malware in the future
Push for Coreboot then.
OpenFirmware that the PowerPC macs and SUN used worked pretty well (and standardized some of what apple did with custom ROMs prior to OpenFirmware). When Apple moved to Intel, going to bios would have been a step backwards. Since Apple was working closely with Intel, they went with EFI for modern firmware that provided similar features as OpenFirmware. I am not sure if OpenFirmware could have worked in an Intel environment or not, but I am sure Intel was pushing for them to use EFI anyway as a showcase since the PC market was not adopting it as expected.
Apple became a early adopter of EFI in the consumer market. The boot process could be faster by skipping legacy modes and have full access at boot to modern hardware making plug & play much more reliable. liked the idea of EFI… The main downside was that OSes needed to be updated to support it properly.
As EFI has become UEFI… the only part I don’t like is SecureBoot. I am concerned that it is better at locking out people from using the OS they want more than securing it from threats.
As for the article. Is giving the WIFI direct DMA access after the OS boots a bug or was that just how a net boot was expected to work?
Edited 2012-03-19 16:11 UTC
Ah yes, what happened to Open Firmware? (and quickly checking out http://en.wikipedia.org/wiki/Open_Firmware then http://en.wikipedia.org/wiki/OpenBIOS#Provided_implementations – x86 implementations seem to be around, even in one somewhat popular machine, OLPC XO-1; so it couldn’t be much of a tech issue)
Was there something wrong with it? Anything more than “people aren’t used to Forth” (yeah, like we really want run-of-the-mill devs messing around with firmwares) or… “it’s not from Intel”?
With Intel & UEFI, it’s maybe a bit unfortunate that, when introducing AMD64, AMD didn’t kill two birds with one stone (or: roast two meals on one fire, as we would say around here, a more uplifting thing …hm, though maybe with bird meat, anyway & despite me writing at first “kill two fish…” which didn’t sound right)
All I want in a firmware is something that can read a kernel from a filesystem, boot it and GTFO.