search

pbatard / EfiFs

EFI FileSystem drivers
https://efi.akeo.ie
GNU General Public License v3.0
521 stars 79 forks source link

EDK2/VS2019 built drivers for ia32 and aarch64 are missing susbsystem and other data #20

Closed pbatard closed 4 years ago

pbatard commented 4 years ago

Per pbatard/rufus#1213, the ia32 and aarch64 versions of the EDK2 drivers compiled with VS2019 don't populate the following fields from the PE Header:

Image3

The gnu-efi version for all archs, or EDK2 version for x64 and arm don't have that issue (and the signature field is missing then, which is probably related):

Image5

We definitely want to have cpu and subsystem filled out, as we suspect that some UEFI firmwares may refuse to load a driver that doesn't have those. At first glance, it would look like some of the post processing that is meant to happen to convert a DLL to an EFI binary is not being applied to the AARCH64 and IA32 targets...

pbatard commented 4 years ago

This is getting better and better. If I recompile using current EDK2/VS2019, then the fields are now populated as expected for IA32. But the AARCH64 problem remains and, what's more, the same issue exists with the gnu-efi/VS2019 version of the AARCH64 drivers.

So this does not look to be an EDK2 vs gnu-efi problem, but a VS2019 problem, and most likely, if I had produced gnu-efi based IA32 drivers instead of EDK2 based IA32 drivers at the time of the 1.5 release, they would have suffered from the same fate.

This is 100% a VS2019 linker bug, because we are definitely setting:

/MACHINE:[X86|ARM64] /DLL /ENTRY:_ModuleEntryPoint /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER

when we invoke link.exe, and I have confirmed that these flags appear to be completely ignored.

And what's more it appears that the AARCH64 version of this bug has existed forever and that, not happy to only screw up AARCH64, Microsoft recently introduced that same bug in the IA32 version, right around the time where I released EfiFs v1.5, and then fixed it with a subsequent VS2019 update...

pbatard commented 4 years ago

Aha, at least I have an explanation for the IA32 issue. This has to do with a typo in the release.cmd script I use to rename and reorganize the drivers, where we picked the drivers from AARCH64 directory instead of IA32. So of course, if you try to load that on an IA32 system, you're going to run into an error, and you are also going to see the same missing fields as the ones from AARCH64, since the drivers are the same.

At the very least I need to upload a new version of the IA32 drivers on the website, as the current ones will not work.

pbatard commented 4 years ago

With the above clarified, I'm going to go on a limb and assume that, rather than link.exe having a major bug, it's rather that Pestudio has not been update to process ARM64 executables (coz I did test yesterday with the newer version that was released just this month, and saw empty fields for AARCH64)...

And indeed, readpe from the pev suite on Linux does see the machine, subsystem and other fields properly populated.

Sigh; never put your trust in proprietary software...