Old engine needs to respect file alignment requirements (instead of aligning to 8 bytes)

[guub187]

Hi,
I'm trying to make a mod for an Asus Maximus V Gene board (latest bios 1903) from here:

https://dlcdnets.asus.com/pub/ASUS/mb/LGA1155/MAXIMUS-V_GENE/MAXIMUS-V-GENE-ASUS-1903.zip

But I've found an issue: when I open the bios using the A58(new engine), some "parseFileHeader: file alignment 10h is greater than parent volume alignment 8h" warnings appear... and a "pad-file" is generated just after the SandyBridgeGop DXE driver.

If I open it with the 0.28.0, no alignment warning appears, but I simply cannot remove any DXE driver or the bios will be incorrectly re-generated and the board won't boot.

However, if I remove the IntelSnbGopDriver, the "pad-file" dissapears and, then, I can remove some DXE drivers and everything works ok.

So I think you have a small bug there. I'm not sure but perhaps the IntelSnbGopDriver's code includes some kind of microcode-GUID chars inside "17088572-377F-44EF-8F4E-B09FFF46A070" and your UEFITool's 0.28.0/A58 parser thinks is a new microcode section when are just some GUID chars inside the DXE driver code...

Thanks.

[NikolajSchlej]

The bug there is that Microcode file and all other files that are 16-bytes-aligned are not preserving the alignment of the file, and instead are using the alignment of the volume. This is not a bug in UEFITool, but in the ASUS image itself. You can enforce correct alignment manually by selecting all 5 pad-files (they are real, and used for aligning the following file) one by one and applying "Do Not Rebuild" action to all of them. If you do that, the resulting image will most likely continue to work.

[NikolajSchlej]

Citing the UEFI PI spec:
"Alignment. The first byte of a volume is required to be aligned on some power-of-two boundary. At a minimum, this must be greater than or equal to the highest file alignment value."

UEFITool NE added a check for it after UEFITool 0.2x development had been done.

[NikolajSchlej]

I stand corrected, the aligning function doesn't respect volume alignment, just uses hardcoded 8 byte default:

UEFITool/ffsengine.cpp

Line 3464 in 44cafeb

// Align to 8 byte boundary

Reopening the bug to fix it.

[guub187]

Ok, I'll test it when the patched 0.28.x version is released.
Many thanks!

[82ghost82]

Add me to testers!
I think I have the same exact issue with a Asus Z9PE-D8 WS bios file (5802), pad file added on rebuild after modifying AmiBoardInfo, resulting in not bootable system.
Many thanks from my side too!

[NikolajSchlej]

I'm mass-closing all issues that are specific to the old engine, because no further work is planned to be done on it, and all the bugs that are present there are to remain there forever. The original engine had a good run, but it needs to go in peace.

[malavon]

I'm just here to tell you that this issue was closed incorrectly. The same errors show in NE A 67, at least in FreeBSD but I'm quite sure that's not related. It doesn't show in 0.28.0 though. The screenshots at the top of this issue confirm this, it's a problem in A 58 but not in 0.28.0.
I'd say it's probably safe to say it's not part of the old engine, but rather the new one.

Cheers!

[NikolajSchlej]

It doesn't show in 0.28.0 because there was no such check in 0.28.0. It's not an issue in UEFITool NE, but in the image itself, and UEFITool NE is correct to identify it and report on it. The issue with incorrect alignment during rebuild (that is indeed present in 0.28.0) is not present in NE because there's no rebuild code in it just yet.