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

[Rui Ueyama via llvm-dev]

Hi,

lld-link already has an option to specify version. Please try to add
"/version:14.0" to your command line.

As to whether we should set it to 14.0 (or some other version number) by
default or not, we probably should. The reason why I didn't do that until
now is just because I didn't see a need for that, but if a Microsoft tool
expects some value there, there's no reason to not do that.

On Wed, Jun 21, 2017 at 1:25 AM, Simon Tatham via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170621/0f370433/attachment.html>