Hacker News Reader

> note to self: I haven't yet checked whether any of the *BSDs can read EFI variables in general and on this hardware in particular

Good news: FreeBSD is able to read the whole variable list.

Bad news: I just wiped my test drive with all the in-progress kernel patches by accident.

Glad to hear FreeBSD worked. Sorry you wiped your drive though!!

One thing I've gotten used to over the years is Linux complaining that some part of the machine's EFI is buggy no matter what machine it is installed on. Apparently it's just too complicated for hardware manufacturers to get right. I also feel like there is far too much duplicated effort in the industry with everybody making their own version that is slightly buggy in a unique way.

It is just moving the complexity around.

In the old BIOS + ACPI days, the OS carries hardware specific hacks. These hack were buggy and hard to keep to day.

We (the community as a whole) decided it is better leave the hardware specific hacks to the hardware, UEFI was supposed to provide enough abstraction for all we need.

The result is, of course, the hacks with all its bugs are moved to the firmware.

> The result is, of course, the hacks with all its bugs are moved to the firmware.

More realistically, we now have them in all the places because vendors. :)

FreeBSD can read and manipulate EFI variables in general. It would be interesting to see what happens when you try efivar or efibootmgr in FreeBSD.

Grab the memstick image from here: https://download.freebsd.org/releases/ISO-IMAGES/14.0/

Uncompress it, and dd it to your USB drive. (dd if=FreeBSD-14.0-RELEASE-amd64-memstick.img of=/dev/sdb bs=1m conv=sync, assuming sdb is your usb stick..)

Makes sense! I wonder if there is a way to dynamically watch the Windows call, to compare it with the Linux one, to avoid the tedious reverse engineering. Or if the syntax of Windows GetNextVariableName() use is generally understood/documented?

This could happen either through somehow getting logging from the Windows end, or somehow changing the UEFI to be one you control and logging there, or finding a different BIOS/OS that can read the vars and getting it to log its work.

> Makes sense! I wonder if there is a way to dynamically watch the Windows call, to compare it with the Linux one, to avoid the tedious reverse engineering. Or if the syntax of Windows GetNextVariableName() use is generally understood/documented?

The userspace interface is somewhat documented by third-parties (because it is technically internal). However, the important parts happen kernel side, and I'd rather avoid diving too deep into Windows because some very interesting job postings (understandably) have "No exposure to Microsoft code or reverse-engineering of Microsoft software" in them.

I already tried getting to the service handler implementation via Linux, but memory protections made it weird enough that I was even questioning whether it was returning correct raw data when trying to read it from memory (or I have been looking at the wrong set of headers).

> or somehow changing the UEFI to be one you control

wouldn't that be trivial simply using a VM?

I don't know a thing about BIOS internals, so this might be completely irrelevant

Last I checked (which was about a decade ago) Windows doesn't call GetNextVariableName() - it just accesses variables on demand. We should probably handle that in a cleaner way.

It seems like that is no longer the case. I was able to successfully retrieve a non-standard variable using the `UEFIv2` PowerShell module [1] (which is just a thin wrapper around the undocumented `NtEnumerateSystemEnvironmentValuesEx` function) without actually naming the variable in question.

To the untrained layman like me, this sounds like Windows actually is querying via `GetNextVariableName`, because UEFI doesn't seem to offer any other interfaces that aren't "get/set variable by name".

[1] https://www.powershellgallery.com/packages/UEFIv2

Ok, yes, sounds like it is in that case. Which means figuring out how Linux is doing this differently to Windows, sigh. The easiest validation is to boot Windows under qemu with a debug-enabled EDK2 build to trace the calls.

> The main issue with fixing it properly is that I'd most likely have to reverse engineer the Windows kernel or the UEFI firmware itself

Before doing such complicated things, have you tried with RU.EFI?

I haven't, and (as I already said) I also haven't tried any of the BSDs yet. I put both on the list of things to try.