[Spice-devel] Win7 64-bit QXL driver (binary) is not signed properly

[Tsukasa #01 (Oi)]

Basically this post is the same issue report discussed in threads:
http://lists.freedesktop.org/archives/spice-devel/2013-January/012157.html
http://lists.freedesktop.org/archives/spice-devel/2013-May/013307.html
but with a possible solution (which Red Hat and/or KMCS+Authenticode
certificate owners could test).

I understand this is not the right place to report this issue (because
you don't sign the binary, Red Hat does) but I am reporting because I
think forcing 64-bit Windows users to use test mode for users of
<http://www.spice-space.org> is not a good idea.


[What is happening]

In Windows 7 x64 guest with default configuration, QXL device does not
work after automatic installation of spice-guest-tools-0.59.exe,
spice-guest-tools-0.65.exe or after manual installation of qxl.inf (I
believe any signed binaries by Red Hat except driver included in Red Hat
Enterprise Virtualization) with error code 52. Disabling integrity
checking and enabling test mode (by modifying boot options) will work as
a workaround but these changes will make security violations.


[What is expected]

QXL device work (installer may generate warning though) without
disabling integrity checking or enabling test mode.


[What is suspected for causing this issue]

In short, driver file qxl.sys and catalog file qxl.cat are not properly
signed (unlike other SPICE + Red Hat binaries such as netkvm.{sys,cat}).
It looks they are signed by Red Hat (actually, it's signed using
Authenticode) but they don't have proper signatures for drivers.

64-bit Windows requires Kernel Mode Code Signing (KMCS) for drivers
and/or any PE modules which is marked integrity-checked. The point here
is, KMCS enforces modules to be trusted by Microsoft (directly or
indirectly through cross-certificate). This is *not just Authenticode*.

Differences between KMCS (+Authenticode) and standard Authenticode are
totally invisible from standard right-clicking method (I think this is
the reason which made confusion in previous threads) but you can confirm
using method described at:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff553929.aspx

You can easily see the difference. Except of RHEV's one,
"signtool verify /kp /v /c netkvm.cat netkvm.sys" returns success and
"signtool verify /kp /v /c    qxl.cat    qxl.sys" returns error (/kp is
the option to verify using KMCS policy).

I verified RHEV drivers (which is not causing errors but a bit old) too
and I found the only reason 64-bit Windows accepts RHEV's QXL driver is
because qxl.cat (the catalog file) is correctly signed by Microsoft
(qxl.sys isn't properly signed but it works because of valid WHQL
catalog file which is installed together).


[Possible solution]

If my guess is right, this issue can be fixed by Red Hat. Specifically,
code signing process can be fixed to use proper cross-certificate, which
extends chain of trust from Microsoft (single root authority) to
multiple CAs.
I believe these links below will help Red Hat to fix this issue because
Red Hat's code signing certificate is issued by VeriSign (Class 3)
authority and Microsoft already has cross-certificate for that CA.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff549832.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff549830.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/dn170454.aspx

Adding "/ac" option to signtool command is the point. This option
accepts cross-certificate file for argument and adds digital signature
for cross-certificate along with standard Authenticode's one.

I hope this will help Red Hat and SPICE + Windows guest users.

Regards,
Tsukasa