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).
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".
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.
Comments
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.
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).
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.
wouldn't that be trivial simply using a VM?
I don't know a thing about BIOS internals, so this might be completely irrelevant