Comment by AshamedCaptain | Hacker News Reader

Comment by AshamedCaptain | Hacker News Reader

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.

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...

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)

[1]: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-gui...

Easier than writing a native MS-DOS program, for sure.

I'm not so sure about that. Especially when AFAIK you need to use a rather large toolchain to access the obtusely indirect APIs.

    xchg ax. bp
    mov dx, 107h
    int 21h
    ret
    db "INT 21 forever!",13,10,"$"

> 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.

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

Edit: Here's a minimal example using clang from someone else: https://github.com/AndreVallestero/minimal-efi

Sounds like how Windows COM (Component Object Model) works.

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.

>Wait until you learn that MS has hooks for the firmware to download executables that will run during kernel boot time...

Could you elaborate? Sounds very sinister

This might be about ACPI's Windows Platform Binary Table, which allows malware like Superfish to persist across installations.

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+).

References:

https://wiki.ubuntu.com/Kernel/Reference/WMI

https://raw.githubusercontent.com/microsoft/Windows-driver-s...

https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-...

https://github.com/pali/bmfdec

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.

Future computer archaeologists will use ancient lost knowledge like this to hack our AI overlords and re-purpose them to once again do our bidding.

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)

Is it the same mechanism that's used by Computrace / Absolute?

Computrace uses WPBT, which is one of them.

Reply on news.ycombinator.com