In virtio-win-0.1.185 and virtio-win-0.1.190, signatures for some NetKVM and viostor driver packages are invalid

[alexey-buluy]

We're using these drivers, installing them in unattended mode. I've noticed what NetKVM and viostor driver packages for:

xp
2k3
w7
2k8
2k8R2

are refusing to install in unattended mode. I've checked them using SignTool and they aren't passing the verification:

`
d:\virtio-win-0.1.185\viostor\2k8\amd64>SignTool verify /v /c viostor.cat /pa viostor.sys viostor.inf

Verifying: viostor.sys
File is signed in catalog: viostor.cat
Hash of file (sha1): 2846A614D102616D1D4A8EE8039124DA2BFEB05E

Signing Certificate Chain:
Issued to: VeriSign Universal Root Certification Authority
Issued by: VeriSign Universal Root Certification Authority
Expires: Wed Dec 02 02:59:59 2037
SHA1 hash: 3679CA35668772304D30A5FB873B0FA77BB70D54

    Issued to: Symantec Class 3 SHA256 Code Signing CA - G2
    Issued by: VeriSign Universal Root Certification Authority
    Expires:   Mon Jul 22 02:59:59 2024
    SHA1 hash: 1392E4C7FF25B9517E931077BBE2664DC87EF70D

        Issued to: Red Hat, Inc.
        Issued by: Symantec Class 3 SHA256 Code Signing CA - G2
        Expires:   Wed Jan 26 02:59:59 2022
        SHA1 hash: F01DAC89598C52D94FE8CA91187E1853947D115A

The signature is timestamped: Thu Jan 09 04:30:05 2020
Timestamp Verified by:
Issued to: VeriSign Universal Root Certification Authority
Issued by: VeriSign Universal Root Certification Authority
Expires: Wed Dec 02 02:59:59 2037
SHA1 hash: 3679CA35668772304D30A5FB873B0FA77BB70D54

    Issued to: Symantec SHA256 TimeStamping CA
    Issued by: VeriSign Universal Root Certification Authority
    Expires:   Sun Jan 12 02:59:59 2031
    SHA1 hash: 6FC9EDB5E00AB64151C1CDFCAC74AD2C7B7E3BE4

        Issued to: Symantec SHA256 TimeStamping Signer - G3
        Issued by: Symantec SHA256 TimeStamping CA
        Expires:   Fri Mar 23 02:59:59 2029
        SHA1 hash: A9A4121063D71D48E8529A4681DE803E3E7954B0

Successfully verified: viostor.sys

Verifying: viostor.inf
SignTool Error: File not found in the specified catalog.
SignTool Error: File not valid: viostor.inf

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 1
`

The rest of the drivers (starting from w8/2012 and up to w10/2019) are passing the verification fine.
Due to this, for listed OS I have to roll drivers back to release virtio-win-0.1.141 - in this release, ALL packages are passing verification. So signatures clearly broke somewhere in between virtio-win-0.1.141 and virtio-win-0.1.185.

Also, additional issue - in w7 and 2k8R2 packages, in catalog file, there are wrong inf filename: netkvm_no_rsc.inf instead of netkvm.inf

I've tested only NetKVM and viostor driver packages but I'm suspecting it is the same for the other drivers too.

[alexey-buluy]

Most likely this issue: #41
Is caused by this one

[alexey-buluy]

@vrozenfe

Any updates on this? It's quite critical.

[vrozenfe]

@alexey-buluy
Sorry for delay in response.

The last good one SHA-1 signed drivers should be in build 174 from 12/12/2019.
We don't build pre-Win8 drivers any longer, but we keep distributing the old
ones. It used to be a problem in rpm 185 that was coming with old drivers from
build 175. Unfortunately build 175 was broken due to SHA-1 signing deprecation.
This problem should be fixed in rpm 190

Regards,
Vadim.

[alexey-buluy]

@vrozenfe

But build 174 aren't available from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
It's simply not there. Am I looking in the wrong place? Checked others in there, builds of version 173 and prior aren't usable, as certificates expired already, and 185 and later has broken signatures.

It's OK about the distributing the old drivers for pre-Win8, but they still need proper signatures, so it will be a good idea to re-sign them using the latest certificates. Because while I totally could install the new trusted CA certificate in the system to make verification work, I cannot make the obsolete certificate working again after its expiration date. Pre-Win8 operating systems still widely used in banking, healthcare, etc and doesn't seem like they will be retired any time soon, unfortunately.

[vrozenfe]

Can you try 190 (https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.190-1/)
This rpm is a mix of new drivers (build 190) for Win8 and higher and old drivers for WinXP/WS2003/Win7.

Unfortunately , it is not possible to resign the old drivers for a couple of reasons. SHA-1 is deprecated ( https://docs.microsoft.com/en-us/sysinternals/announce/sha1deprecation ) and we don't have any valid SHA-2 certification
to run a cross-signing process on Win7 drivers. The cross signing process itself is also deprecated since Feb 22 2021 ( https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates )

We are going to provide community with attestation signed drivers ( https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release ), even though that this solution will work for Win10 drivers only.

Regards,
Vadim.

[alexey-buluy]

@vrozenfe

Checked 190 - signature certificates are OK, but driver catalog seems flawed - SignTool verifying the signature for netkvm.sys correctly, but can't find netkvm.inf in the catalog, like it was edited after making the signature:

Successfully verified: netkvm.sys

Verifying: netkvm.inf
SignTool Error: File not found in the specified catalog.
SignTool Error: File not valid: netkvm.inf

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 1

[vrozenfe]

Hi Alexey,

So, does it fail to install on your system? What is your Windows OS version and the drivers installation
path/location on virtio-win iso?

Vadim.

[alexey-buluy]

@vrozenfe

Hi Vadim!

To give the context:

We're using our own automated virtualization system based on KVM. To improve networking performance, we're trying to use VirtIO networking adapters instead of emulated E1000. We're testing it with ALL client and server versions of Windows of both architectures, and to make the process seamless we're integrating the VirtIO drivers directly inside the offline VMs before starting it, so when Windows will start and detect the VirtIO Ethernet adapter, it will already have the required drivers and could install it automatically without ANY user interaction.

To make this work, it is required for drivers to have proper signatures, as without that, depending on the version of Windows, it will either refuse to install the drivers completely or will ask the user for permission to install the driver with improper signature.

So, the issue is not what it fails to install on some systems, the issue is what it fails to install seamlessly without user interaction. With full user interaction, we're able to install them, but it's not what we need or want. So, what we currently got on our hands:

For Windows versions:

Windows Server 2012
Windows Server 2012R2
Windows Server 2016
Windows Server 2019
Windows 8
Windows 8.1
Windows 10

For both x86 and x64 - drivers from release 185 integrating correctly as they have valid signatures, and installing correctly without user interaction after system starts. But for the rest:

Windows Server 2003 and XP - driver signatures invalid for build 185, so system always asking user to allow to install the unsigned drivers. Can't work it around due to https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/298503
Tried drivers from release 141 - driver is signed properly in there, but certificate is expired long ago, so it's also treated by system as unsigned. As a result, wasn't able yet to integrate any version of drivers for these systems seamlessly.

Windows Server 2008/2008R2/7 - driver signature invalid for build 185, so always asking user to allow to install the unsigned driver. Was able to seamlessly integrate drivers with proper signatures from release 141 properly after also injecting the required certificates into the system, but there is another issue - for x86 systems of this family, driver release 141 aren't working properly - Ethernet adapter aren't properly initialized and always says "Media disconnected", so there is not much gain in that as only x64 systems able to use it.

Regards,
Alexey

[tom-i]

@vrozenfe I have similar problem with VirtIO drivers for Windows Server 2019 version (virtual machine). Installation process can't use any of viostor, vioser and so on.
I've tried many ISO versions, also latest (0.1.204), but with no luck :-/

EDIT: I've fixed this with using older Windows Server 2019 image

[vrozenfe]

@tom-i
If it works with one Windows Server 2019 distribution media but fails with other then it might be that the image has been corrupted or altered from the original. Can you verify the problematic iso image hash?

Thanks,
Vadim.