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

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

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>

> From: Rui Ueyama [mailto:ruiu at google.com]
> Sent: 21 June 2017 15:23
> 
> lld-link already has an option to specify version. Please try to add
> "/version:14.0" to your command line.
That doesn't affect the same version field. The number I put in there goes
into the MajorImageVersion and MinorImageVersion fields, whereas to solve this
signature issue I need to control MajorLinkerVersion and MinorLinkerVersion.

Cheers,
Simon