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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel