[llvm-dev] [LLD][COFF] Zero linker-version header field breaks Authenticode on Windows 7

[Simon Tatham via llvm-dev]

Hello llvm-dev,

I've recently been using clang-cl and lld-link to build Windows PE executables, which I then code-sign with Authenticode. I've found that although the resulting signed executables seem to validate successfully on Windows 10, they don't on Windows 7: right-clicking on one and bringing up the Windows Properties dialog shows either no 'Digital Signatures' tab at all (for a 32-bit binary), or one in which Windows says the signature doesn't validate.

After some experimentation, it appears that this is a consequence of the 'linker version' field in the PE header being zero! lld-link sets both the MajorLinkerVersion and MinorLinkerVersion bytes to zero; Visual Studio's linker (as of VS2015) sets MajorLinkerVersion to 14. And if I patch lld to set MajorLinkerVersion to 14, the problem goes away, and my signed lld-linked executables validate just fine on Windows 7 as well as 10.

I have no idea why this happens, though I speculate that if Windows is depending on the linker-version field at all then it's probably using it as a trigger to enable or disable particular bug workarounds (and making the unwarranted assumption that only one linker exists). But regardless of the reason, I think it would be more useful if lld-link wrote a value into that field that makes this use case do the right thing.

Does that sound reasonable? If so, I'll prepare a patch. (Though I'm not sure whether I should do the trivial thing of just writing a value I know to work, or whether I should invent a command-line option to tell lld which version of Visual Studio's linker it should claim to be. The latter would be consistent with clang-cl's configurable compiler-version emulation, I suppose.)

Cheers,
Simon