The author is exaggerating quite a bit. Nothing is intrinsically complicated about writing a UEFI "application" -- UEFI sadly even specifies this. Someone even ported DOOM. They did it for jiggles -- but it's hardly "completely new forms of software". Easier than writing a native MS-DOS program, for sure.
Some company even sold laptops with two CPUs, one that would run some Windows CE while the main Windows was booting. Even that is just gluing a PDA and a laptop together...
BIOSes "perverting" sleep behavior? Sleep is precisely what the BIOS handles. E.g. way before Windows would support hibernation natively, laptops with hibernation capabilities would have to do it all on firmware. And it wasn't that fragile, since it would work with everything from MS-DOS to Linux (even the progress bar UI which was some VGA text mode). This is how I learn in the 90s that Windows likes to keep unused pages zeroed while Linux does not: hibernation under Linux would take significantly longer. But it'd work.
I was personally somewhat hoping the boot-time portion in this article somehow hijacked a UEFI runtime services[1] function called by the OS to draw to the frame buffer set up by the firmware, since this has some provisions for the OS being in charge of the MMU:
> An OS may choose to execute in a virtual addressing mode and, as a result, may prefer to call firmware services provided by UEFI Runtime Drivers in a virtual addressing mode. A UEFI Runtime Driver must not make any assumptions about the type of operating system to be booted, so the driver must always be able to switch from using physical addresses to using virtual addresses if the operating system calls SetVirtualAddressMap().
Disappointingly, it's just a 'plain' case of SMM (which is also, funnily, the main target for ACPI callouts to more 'complex' methods, and on ARM has the very fun equivalent called 'SMC/HVC callouts to EL3/EL2 firmware' although that's supposedly a bit better-defined than Intel SMM) and nothing too clever either - an ACPI method hijacking something to then write to the framebuffer?
Other than that, the writing style here feels almost.. presumptuous and might've been written for the original audience on the site it's posted on, for example I was left wondering things like 'if the author or their friends have access to a machine with this software on it, why don't they dump the firmware flash storage and decompile the actual images, wherever they might be', though it may be they indeed didn't have access to any such hardware or firmware downloads and are just piecing random puzzle parts together, and the post eventually devolved into a general rant against OEM cleverness that I somewhat skipped.
(I'm also mildly torn between 'wow, clever hack' and 'oh lord this would be terrible to diagnose OS boot issues on as you really can't trust OEMs with side effects or long-term maintenance' in this regard)
You don't need any sort of large toolchain. In short, a UEFI application works like this (from memory so some details may be wrong): The system calls your main function with a parameter for the address of a struct. That struct contains a function pointer which you can call to get other structs known as protocols. Those protocols contain function pointers which you use for everything else (putting images on the screen, setting callbacks for keyboard input, making network requests, etc.).
All you need is the function signatures and the constants to lookup the protocols, it's no more than you need to use any other C library. I can tell you from experience that if all you want to do is textual IO you only need a few hundred lines of header files: https://github.com/liampwll/zig-efi-os
Getting the GNU EFI toolchain to work is somewhat involved. The result is also convoluted for reasons I don’t understand. For example, it uses a perfectly normal GCC that is perfectly capable of defining and invoking __stdcall functions, but instead it has assembly thunks you’re supposed to use to translate to and from __cdecl. AFAICT it shouldn’t be that much harder than a bunch of header files, a freestanding compiler invocation with a custom crt0 and an objcopy to make the PE file (OK, yeah, PE relocations are different from ELF ones, but still), yet the standard C setup you’ll find on OSDev Wiki or similar is, in fact, quite annoying to use.
I've never actually used gcc to target UEFI, but under Clang and other LLVM based compilers it really is just a few flags and header files. If I recall correctly my little demo linked above predates any sort of UEFI support in zig and just uses what LLVM provides, you can see how straightforward the whole thing is in the makefile (the little bit of assembly is unrelated to UEFI): https://github.com/liampwll/zig-efi-os/blob/master/Makefile
That struct contains a function pointer which you can call to get other structs known as protocols. Those protocols contain function pointers which you use for everything else
That's what I mean by "obtusely indirect".
if all you want to do is textual IO you only need a few hundred lines of header files
"only need a few hundred lines"? That's huge in comparison to MS-DOS.
They could've made UEFI almost like MS-DOS in API too, just with a flat address space. Yet they came up with a monstrosity far more complex.
> Especially when AFAIK you need to use a rather large toolchain to access the obtusely indirect APIs.
Weight that (literally only a couple macros) versus the idea of having to dig out a 16-bit toolchain and/or a DOS extender which also brings its own obtusely indirect APIs with it. In case you decide to do the former, you'll probably have to rewrite big chunks of your program in order to rearchitect it around XMS. In case you decide to do the latter, you'll be able to use a 32-bit toolchain, but you'll have to write your own drivers for high-resolution graphics, sound, and depending on your luck, mouse. All of this UEFI brings for free, and even for recent hardware.
There is WPBT ACPI table which may contain PE executable saved as \Windows\System32\Wpbbin.exe and executed at boot time (supported by Windows 8 and above). Official specification is here: https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-...
Also there is an unofficial method of running firmware-initiated VBScript in the all versions Windows starting from Windows 2000. There is a special type of ACPI devices (PNP0C14, "Windows Management Instrumentation Device") which is handled by Windows builtin driver WMIACPI.SYS. This type of ACPI device can export (via ACPI bytecode) various data fields and methods for Windows subsystem WMI/WBEM (think CPU thermal sensors; laptop backlight control; on/off switches for builtin camera/wifi/bluetooth hardware, which can be managed by Windows tray utility supplied by laptop vendor etc), as well as binary MOF which contains WMI metadata for these fields and methods. Besides primary purpose, this binary MOF can be constructed in such way that VBScript code is executed immediately in the MOF parser context (wmiprvse.exe, a builtin Windows service). Windows DDK has various MOF-related tools like compiler, verifier etc; as well as some samples. Binary MOF is compressed, but its format has been reverse engineered (it uses an old compression algorithm from Microsoft DoubleSpace). This method for running firmware-initiated VBScript works for all versions of Windows starting from Windows 2000, including WinPE-based Windows Setup (Vista+).
You mentioned the two methods I had in mind. These days there is a third one, but it seems to require cooperation from Windows Update. MSI (for example) uses it. As far I as can see, they simply create a fake ACPI node for which Windows Update will silently download a "driver", which in turn downloads the crapware.
Fun thing is that laptop OEMs exposing useful 'value-added functionality' (like custom fan control) via pre-defined WMI ACPI callouts is actually the sensible choice to make.
I've seen laptop OEMs that rely on a custom kernel driver for this, and then if you want to reimplement their pile of 'overly modular everything control suite' you're stuck loading a generic read/write-memory driver which is blocklisted by every antimalware and anticheat solution in existence.
(In addition, it seems some WMI/CIM/MOF ACPI stuff is supported on Linux fine, too, as long as OEMs try to stick to standard DMTF-spec stuff I guess... so one can also just do 'generic' user-space stuff there if lucky)
1) The PC, loaded with any security contraption you can think of and severely underprovisioned in RAM is deemed user-worthy by IT if it boots in 15 minutes or less. It may take 10 min from desktop visible to can actually move the mouse.
2) Work day start and end are logged in a web application, requiring a running PC.
3) Shutdown takes just at long.
4)Sleep modes don't work. Fresh boot every day, or weird crashes will haunt your whole working day .
So how, as a worker drone, do you avoid adding an hour of working time just waiting to start and end the work day?
Very predictably, once end users found out the firmware based browser, there was no stopping them. And then they found the browser could surf to sites without said security contraptions blocking them.
Working inside any huge ( non tech ) or government system, along with quite literally broken VPN or networking. Yes, you spend at least 1 hour per day just starting up the machine, wait for it to connect, and downloading things on a slow network. Along with unresponsive Application using things like Team.
Most people in the decision making grade have absolutely no clue about tech, be it software or hardware in general.
> Was this worth it? Worth inventing completely new forms of software, worth injecting code into the fucking thermal management layer that overrides parts of the Windows boot sequence and risks corrupting main RAM and rendering the machine unusable, all for a fucking 15 second speedup?
It also feels like the case of some higher up VP-of-whatever not realizing how atrocious the implementation would be, and just ordered it to be done. Nobody below them in the development or engineering teams dared to chime in and protest. Those who protested probably found themselves without a job, or replaced by some overseas contractors who never object to anything (and are usually cheaper per line of code written too, a win-win, surely!).
Despite the limitations and hackiness of the approach, this instant-boot feature at least attempts to serve the user?
I don't see any "rate your experience" popups, nor login/signup prompts, nor ads, nor endless amounts of whitespace and the (few) options hidden behind a catch-all "burger" menu.
This thing was actually built to a much higher UX standard than most software nowadays.
> Imagine being a product designer at HP, in the very weird year of 2010, and having some fucking VP storm in and go "We have to deliver Features for Executives. We're selling $1500 notebooks to them, but Dell has exactly the same set of ins and outs as us. We need Features."
Well, I bought a ZBook from HP in January 2014 because of these Features:
1. All the laptops I worked with (my company's or my own) were HP and they were good. They were of the Compaq lineage, not the consumer specs.
2. They have on site next business day support as long as I pay a warranty. That was less than 100 Euro for the first three years. I don't have to bring the laptop somewhere or leave it there for days or weeks.
3. I can open it and replace basically every single part.
4. I knew it would run Linux reasonably well. That means perfectly as long as I don't care that shutdown is a reboot and I have to long press the power button at the BIOS screen to actually shutdown. Maybe I didn't shutdown once since January this year.
5. It has three physical buttons on the touchpad. I wish it didn't have the numberpad.
6. It could accommodate up to 32 GB, which it has now. Plus 2 SSDs, 3 TB total. It came with a 750 GB HDD.
So, these are the kind of features I care about. Software gimmicks in the BIOS not really, nor weird multimedia buttons.
Place I used to work bought probably more than a thousand HP Zsomething workstation whatevers for a vastly inflated price each. They were good, but came with lots of stuff we'd never use like a license to some HP supported remote desktop software that ran on Linux. Complete waste of money.
Until the pandemic hit and we had three days to get more than a thousand people working off-site.
Dell might as well have had the same VP at that time, but to differentiate they instead went with generally useless bundled desktop software like the Dell Stage and Dell Dock.
It speaks volumes about the bloat that modern OSs have become when people think of reimplementing their own on top of the successor to BIOS. The EFI environment has a vague resemblance to a 32/64-bit MS-DOS.
I don't find this stuff negative at all, unlike what the author seems to be implying; instead, it reassures me that there's still plenty of old-school "hacker spirit" left in the industry, if you know where to look.
Agreed. The incredulity expressed by the author is overblown. While there is some hackiness to the approach, it isn’t as insane as the tone of the article would want you to have.
I had a chuckle at the “distinguished technologist” on that slide though.
From the original article all these things were meant to give you a faster booting alternative to Windows but then it didn't actually boot significantly faster!
I worked with someone who had previously been a senior engineer at one or maybe more than one hard drive manufacturers.
He told me about a project he had worked on where they collaborated with Microsoft to make something that would make the OS boot significantly faster working with their hard drive. I'm filling in blanks in my memory here, but I think it involved a combination of putting some files in flash memory (hybrid disk) as well as storing files on the spinning disk in the order they'd be accessed.
It worked! They were able to make boot process significantly faster. But consumers would never see it.
The punchline was, it turns out many peripheral devices and drivers rely on the boot process being slow that all kinds of race conditions and intermittent bugs and glitches turned up as soon as they started testing on a wider range of PCs. Even if you solved the dependency and order of scheduling problems on the main thread of the OS loading, devices may have microcontrollers that are slow to come online or drivers initializing independently.
(You might object well doesn't the hardware or driver have a "ready for first query" flag or something like that. Well that depends on hardware manufacturers doing the right thing, thinking of that ahead of time to add it to the interface, and implementing it correctly. This would be something that had never been tested because previously there was always XX seconds before the OS tried to query the device for the first time.)
So the moral of the story is the boot process of x86 PCs is still slow because it has always been slow...
Windows Vista started a crackdown on hardware boot times that Windows 7/8/10 completed. It was one of the reasons Vista was sometimes considered unreliable because it would actively quarantine bad-acting XP era bootup hardware based on timing telemetry. Windows would tell it to boot up minutes or hours after actual system startup, sometimes leaving users with hardware "not working right" because Windows decided it didn't trust that hardware to wakeup right and decided to just not wake it up at all until it was good and ready. If the hardware kept acting up it would sometimes disable the hardware entirely and suggest to the user it was broken hardware.
That's a running thread in the article above and its related posts: "the PC boot is slow, let's do weird BIOS and dual boot hacks" only made sense for one weird, brief moment in around 2009 between a dying breed of XP-era hardware and just before/as Windows itself decided to be judge, jury, and executioner of hardware boot up times.
I suspect they would become relatively faster over time once the Windows installation (filled with bloatware, no doubt from a different part of the same company) became slower.
Oh my god, this is atrocious. Since this is Hacker News, I know someone who worked on this is probably going to stumble upon this. My only question for you is how your liver is holding up these days.
Hey, I have an Elitebook 8540w! I got it out of storage and tried the browser/email button but unfortunately doesn't do anything. (They are capacitive buttons though, does it really work on an EliteBook 8540w?). I don't have the HP_TOOLS partition either, but this would work great for dual booting? If you press the normal power on button it boots in Windows, if you touch the "browser" button it boots in Linux. Will try some more things.
Update: I had the quicklook/quickweb stuff disabled in the BIOS, I enabled it and lo and behold the computer booted when touching the browser button. Cool.
This was much better than I expected. This commenter sums it up well:
"seeing you lay bare this altar to absurdity that HP has laid helps. perhaps what I have built is a little Extra, but I’ll never hijack the windows boot process in ring -1 to show my outlook calendar"
I’d totally befriend a wild Pegasus if they still existed. Imagine having your friend Pegasus fly you everywhere instead of taking the bus for hours. Would have been so much better.
At least in Victorian London, which was being slowly buried in horse-poop, the poop was restricted to the streets. Poop from flying horses would be a lot less pleasant.
> Windows gets itself all ready for sleep, tucks itself in, then tells the BIOS "too eepy! time for bed, S3~" but instead of the S3 reaching the BIOS, OSM intercepts that call. The OS has halted itself, and is waiting to be told that it's time to wake up, but OSM instead proceeds to alter the universe around it ... the OSM will move all the memory pointers around, then reverse the sleep process, causing the machine to instantly "wake" - from a sleep it never actually entered.
> Windows thinks it's taking a nap, but it wakes up as someone else, leaves the house, and commits murders it has no memory of. In other words: Phoenix figured out how to turn the BIOS into a hypervisor. It's almost, almost beautiful, if it wasn't both incredibly fragile and completely uncalled-for. But christ. Christ almighty, what a hack. One could come to tears over it.
There is a software archaeology epilogue waiting to be written, based on artifact reverse engineering and a trail of public breadcrumbs:
Hyperspace was acquired by HP.
Hyperspace creator left HP and founded Bromium (acquired by HP in 2019).
Bromium productized OSS Type-2 Xen (uXen microvisor), copy-on-write VMs in 150ms.
Microsoft cloned Bromium vSentry as Defender - Application Guard.
Bromium AX ships on HP biz laptops /w nested x86 virt for OS+UEFI virt.
OSS Bareflank hypervisor = attempt at replicating AX (Windows-as-dom0).
OSS Android 13 pKVM-for-Arm is closest OSS in spirit to Bromium AX.
In other words, conceptual descendants of the Phoenix Hyperspace hack are shipping today on millions of Android and Windows systems. In 2018, https://github.com/rust-vmm/community#why-rust-vmm deduped CrosVM (Chromebooks) and Firecracker (public cloud) micro VMs on KVM.
Video with virtualization history of Xen (Type 1), uXen (Type 2) and Bromium/HP AX (Type1 L0 for nesting of Xen, KVM, VMware, Hyper-V): https://www.youtube.com/watch?v=bNVe2y34dnM)
The article (and its predecessor) makes a big deal out of "they turned BIOS into a hypervisor!!1!". What exactly does the author think a hypervisor is, other than code running at a heightened privilege level that interposes the running OS's communication with the hardware.
Most of what's happening here is pretty standard that's-how-a-minimal-hypervisor-works. The Outlook-data-migration part is interestingly janky, but not technically complex.
Before UEFI, IBM ThinkPads had an odd implementation of "secure boot", whose purpose I never really figured out (was digging into the BIOS for something else and just happened to notice it in passing, then dig a little bit of RE on) that acts as a hypervisor too.
It's a ROM module with the strings "IBM V86" and "Secure OS boot support ROM", neither of which search engines seem to find any results for (perhaps deliberately?); neither now nor the roughly a decade and a half ago that I attempted to research it. This might now be the only reference to such a thing on the increasingly forgetful Internet.
This is wrong, but just plausible sounding enough that some readers will believe it. The other replies also seem to be nothing but further ChatGPT generated spam from same poster.
---
The V86 mode it's trying to describe here was/is a processor feature introduced by Intel in the 80386. It is not something specific to IBM ThinkPads or normally requires any BIOS component, and was first supported by Compaq's memory manager and Windows/386:
It is reasonable to guess that "IBMV86" also makes use of this feature, though I don't know exactly for what purpose; and as a human, I am perfectly willing to say so instead of making up bullshit.
Yes, I can provide more details on Secure OS boot support ROM and its implementation in IBM ThinkPad laptops.
Secure OS boot support ROM, also known as BIOS-based Trusted Computing or Secure Boot, is a security feature that was first introduced in IBM ThinkPad laptops in the early 2000s. The main purpose of this feature is to ensure that the boot process is secure and tamper-proof, by validating the digital signature of the bootloader and the operating system kernel before executing them.
The implementation of Secure OS boot support ROM in IBM ThinkPad laptops was based on the Trusted Platform Module (TPM) technology, which is a hardware-based security solution that provides a secure storage for cryptographic keys and other sensitive data. IBM ThinkPad laptops that supported Secure OS boot support ROM had a TPM chip embedded in their motherboard, which stored the digital signature of the bootloader and the operating system kernel.
The reason why IBM had their own implementation of Secure OS boot support ROM, instead of using more standard solutions like UEFI Secure Boot, was due to the fact that UEFI was not yet widely adopted at the time. In addition, IBM had their own proprietary BIOS firmware that was specifically designed for ThinkPad laptops, and they wanted to maintain full control over the security features and ensure compatibility with their existing software and hardware.
Overall, Secure OS boot support ROM was a significant security enhancement for IBM ThinkPad laptops, as it helped to prevent unauthorized access and protect against malware attacks during the boot process. Its implementation was based on the TPM technology, which provided a secure storage for cryptographic keys, and it was designed to be compatible with IBM's proprietary BIOS firmware.
I'm going to just outright say that your post is pure ChatGPT hallucination/speculation/misinformation, for the benefit of any future readers coming across this. It says absolutely nothing new about what I found, and will only contribute to more useless results in search engines.
Frankly, the thought of the lesser-known parts of our past being replaced with AI-hallucination is terrifying.
Once IBM V86 is enabled, you can run DOS-based applications on your modern operating system like Windows XP. IBM V86 provides better performance than these emulators since it is a hardware-based solution and does not require emulation.
Some examples of things that made use of IBM V86 include legacy software and applications that were written for DOS-based systems, such as games, productivity software, and business applications. With IBM V86, users could run these applications on their modern 32-bit operating systems without the need for a separate DOS-based system or emulator software. This feature was particularly useful for business users who needed to run legacy software to maintain compatibility with existing systems and processes.
the boot firmware (tf-a, non-eufi) for arm cortex-a has a similar concept, but without shifting quite as much into the firmware.
tf-a boots a "trusted environment" (a secure OS, e.g. op-tee), which defers back to tf-a after initial setup. tf-a then boots the main OS (e.g. linux). apps can be loaded into the TE at runtime, the main OS can defer execution to the TE, and the main OS's scheduler can coordinate with the TE to allow pseudo-preemption. coupled with hardware modules (an SPU, TZC, and GIC) in the fabric, specific interrupts, memory regions, and hardware peripherals can be marked as "secure" (i.e. accessible only by the TE) or "non-secure" (i.e. accessible by the main OS).
what's unique (i think? i may be misunderstanding.) in this case is that the TE is an OS without its own scheduler. it depends on the main OS's scheduler to defer control whenever the main OS deems appropriate. each OS has directly registered their own interrupts, so the firmware is really only handling one interrupt: when the main OS defers to the TE.
Not an expert on these things but that's not my mental model of a hypervisor. What you're describing sounds more like an interrupt handler.... you know, a BIOS routine.
Generalizing massively, a simple hypervisor runs a small amount of code at boot to setup its own state somewhere, and injects its interrupt handlers into various places in the system, and finally chain boots the real OS. When the real OS tries to communicate with the underlying hardware, the hypervisor interrupt is triggered and it does it's stuff.
With modern virtualization acceleration, the hypervisor can enable and handle interrupts for an even wider range of events that it might need in order to efficiently interpose the OS.
A more full-featured hypervisor may start to look like a mini-OS with its own scheduler, etc. But a simple hypervisor is basically like an old DOS Terminate-and-Stay-Resident executable.
OK thanks. I imagined the distinction to be that a BIOS functions as an API and abstraction layer over the hardware, without preventing the OS from accessing it directly, whereas a hypervisor functions as an isolation layer, preventing an OS from direct access, and also thereby facilitating simultaneous hosting of multiple OSes on the same hardware.
> But EFI apps are just binaries, and EFI is a limited "OS" that provides a set of libraries, so you can conceivably write many complex programs to run inside of it.
According to user ‘zaarn’ here on HN, this is not feasible for most use cases:
Disabling that watchdog timer only requires a single function call and does not require exiting boot services. UEFI is big, but it's also incredibly well documented, there's also no reason that you have to use all of it or even know about everything it offers.
abusing hardware features to run a ring level lower than the OS is a huge security problem! Not sure why that seems to be overlooked so frequently in comments?
Stuff like that makes me wonder who buys device for that? Or is that just a business unit that's delusional enough to think this actually increases sales?
Some company even sold laptops with two CPUs, one that would run some Windows CE while the main Windows was booting. Even that is just gluing a PDA and a laptop together...
BIOSes "perverting" sleep behavior? Sleep is precisely what the BIOS handles. E.g. way before Windows would support hibernation natively, laptops with hibernation capabilities would have to do it all on firmware. And it wasn't that fragile, since it would work with everything from MS-DOS to Linux (even the progress bar UI which was some VGA text mode). This is how I learn in the 90s that Windows likes to keep unused pages zeroed while Linux does not: hibernation under Linux would take significantly longer. But it'd work.
No one remembers firmware hibernation partitions? I'd guess that many people do, since Intel tried to resurrect that in the 2015s (e.g. https://www.dell.com/support/kbdoc/en-us/000136460/how-to-us... ).
Wait until you learn that MS has hooks for the firmware to download executables that will run during kernel boot time...