When researching Phoenix Hyperspace for my highly upsetting post on the subject, it was hard to avoid news articles proclaiming that it had been sold off by Phoenix (when they gave up wholesale on their idea of making anything other than BIOSes) and bought up by HP. However, that's where the trail ended; attempts to find out what, if anything, HP had done with it proved fruitless. That is, until two days ago.
So this is only kind of related to Gravis' post but there's a couple of fun threads to pull here:
System Management Mode
To explain this level of absolute fuckery I have to explain about protection rings. You might have heard that x86 CPUs have a few different "modes", real mode, protected mode and long mode. These are the three different main running states of the CPU:
- Real mode: The CPU is basically pretending to be an 8086. 16-bit addressing, segmented memory. To this very day you can launch DOS on a CPU in real mode, as long as the BIOS/UEFI will let you boot it.
- Protected mode: Introduced with the 80286 and then introduced in way that actually works in any useful way in the 80386. Supports virtual memory (pretty critical for "real" multitasking by allowing memory to be remapped in different layouts and set up so that programs can address a lot more memory than the 1 megabyte supported in real mode) and a bunch of other features that were standard on timesharing mainframe systems in the 60s and 70s. Also supports protection rings.
- Long mode: Similar to protected mode but with 64-bit addressing (not really but that's not incredibly important) and a bunch of more or less useless backward-compatibility features turned off.
Protection rings are one of the big features of protected mode and what the mode is partly named for. The x86 CPU supports four rings, 0-3, from highest privilege to lowest. Code running at a lower-numbered ring can access memory at an equal or higher protection level, whereas if code at a higher-numberer ring tries to access memory with a lower protection level, an interrupt is generated to let the OS decide what should happen. This architecture is derived from the Multics operating system, which implemented eight(!) protection rings in software, and the later Honeywell 6180 which implemented them in hardware to support Multics.
In practice, every x86 OS only uses ring 0 for the operating system and device drivers and ring 3 for user programs. OS/2 used ring 2 as well, for some programs with extra privileges, but there's no one still running OS/2 except for about a million ATMs.
System management mode is sometimes colloquially described as "ring -2". What the fuck?
As Gravis describes, SMM is a "higher privilege level" than ring 0, but that's not exactly true, the code runs in ring 0, but it's triggered by a set of interrupts the operating system can't intercept or block, so, in practice, SMM can and does take over your machine at any time and the OS can't affect anything that it does except by jumping into SMM on purpose.
If this seems bad, you're right! It is! It's a huge security problem! Any bugs in firmware SMM code can't be patched over by the operating system or prevented in any way, so it has been and continues to be a vector for a semi-infinite number of exploits including a bunch of NSA's famous rootkits.
Even better? There's a ring -3. It's called the Intel Management Engine; AMD's version is the AMD Platform Security Processor. These are different (and more fucked up and evil) than SMM because they basically act as a front-end processor, again derived from old mainframe technology, which is to say it's a whole other computer that does things like boot the main computer. The ME/PSP is also running all the time, even when the computer is "off" as long as it has power, and can highjack any of the major functions of the machine. This is used for things like wake-on-LAN and a bunch of other enterprise computing functionality you don't need or care about, and has also been a vector for effectively unblockable exploits! Cool!
To round this out, "ring -1" is used to refer to a VM hypervisor, which is probably not fucked up and evil as long as you put it there on purpose.
UEFI Graphics Output Protocol
Gravis points out that there's no graphics acceleration in UEFI, which is almost true. It's usually true. The full explanation is much goofier:
The UEFI GOP, in fact, has a specific hook for 2D acceleration, the Blt() function. This allows you to specify a source buffer, a target buffer, a source rectangle and a target rectangle. It's a bitblt primitive! It's the basic building block of all 2D video acceleration! Except... It doesn't support blend modes or masking, all it can do is write pixels to the screen exactly as represented, meaning there's no useful way to use this to implement sprite graphics, layers, etc. Not only that, but most graphics cards don't implement it in a useful way so the performance is dogshit. It's like it was designed expressly to be almost useful enough to make people waste a lot of time trying to use it and then give up.
