Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtio-win-0.1.217 - issue NetKVM Windows 2k12R2 driver #65

Open
kurgans0 opened this issue May 26, 2022 · 7 comments
Open

virtio-win-0.1.217 - issue NetKVM Windows 2k12R2 driver #65

kurgans0 opened this issue May 26, 2022 · 7 comments
Assignees

Comments

@kurgans0
Copy link

Environment

  • Proxmox VM
  • OS Name: Microsoft Windows Server 2012 R2 Standard
  • Windows Version = "6.3.9600.18969"

Issue
Impossible to install driver on this path .\NetKVM\2k12R2\amd64\

Windows message
Windows found driver software for your device but encountered an error while attempting install it.
Red Hat VirtIO Ethernet Adapter
A problem was encountered while attempting to add the driver to the store.

Workaround
It's working with the driver 2008 R2 (.\NetKVM\2k8R2\amd64)

Source driver
virtio-win-0.1.217.iso

@BentHaase
Copy link

Likely related to #33 and #59 - seems to be issues with the latest "stable" iso and broken driver signature for older OS drivers.

@jgottula
Copy link

It also appears that some drivers (irrespective of OS, I believe) are just self-signed in 0.1.217-1, compared to 0.1.215-2, for absolutely no reason whatsoever. virtio-win/kvm-guest-drivers-windows#769

@YanVugenfirer
Copy link
Collaborator

Microsoft retired cross-signing certificates. Any certificate, other than WHQL certification, will be treated as test signing from now own.
For Windows 10 we are providing attestation signed drivers. But MS don't have attestation signing for previous OSes.

@MatthiasSeu
Copy link

the used self signed certificate is a fault, because the OS did not allow the installation with used RedHat Inc. certificate with following hint:
A certificates basic constraint extension has not been observed:
image

But why usign differnt certificatres at all , because the newer drivers from 2k16 and newer used a certificate where the chain and rootCA is ok.

from my perspectice this newer certificate should also work for the older OS, or not?

@YanVugenfirer
Copy link
Collaborator

@MatthiasSeu Unfortunately Microsoft retired cross signing certificates that were used to sign older OSes.
Windows 10 drivers are signed with attestation signing through Microsoft HW portal. Microsoft isn't signing older OS drivers with attestation signing.

@MatthiasSeu
Copy link

@YanVugenfirer But with this certificate, it's defently inpossible to install the drivers for os w2k12r2 and later.
At the Moment, we use drivers where the certificate is expired, but when you pre-import it into trustet publisher and root ca, you can install it wihtout any troubles via pnputil.

Now I have 2 questions:

  1. Is it complete inpossible to use the old certificate for the new generated drivers for OS w2k12r2 and later?
  2. When question 1 ist inpossible to implemnt, is it possible to make a package, where the old w2k12r12 and later drivers are included, and for the newer os the last one.

Because othervise you can face out the older os versions, or i am wrong?

@CaryJ
Copy link

CaryJ commented Aug 8, 2022

I have tried to install the certificate from the .sys file but still can't get the driver to work.

  • I install both the Red Hat and Symantec(Symantec SHA256 TimeStamping Signer - G3) certs into Local Machine/Trusted Root Certification Authorities and Local Machine/Trusted Publishers.
  • After installing the certs the .sys file shows the digital signatures are ok.
  • I can install the drivers without error.
  • The device initially shows as available in device manager, then switches to unavailable
  • Error is: Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)

Why does it still think there is a problem with the signature after I have installed the certificate? Is there another work-around for this (besides disabling signature checking)?

Update: based on @YanVugenfirer 's comment above I discovered I can install the drivers after setting testsigning:
$ bcdedit /set testsigning on
I would still prefer a method to install the drivers without having to set this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants