Bug 1743480 - Getting (code 52) on Virtio Ethernet drive, windows 10 host.
Summary: Getting (code 52) on Virtio Ethernet drive, windows 10 host.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virtio-win
Version: unspecified
Hardware: x86_64
OS: Windows
unspecified
urgent
Target Milestone: ---
Assignee: Amnon Ilan
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1376048
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-20 05:43 UTC by Oz Dror
Modified: 2019-12-30 11:03 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-30 11:03:17 UTC
Embargoed:


Attachments (Terms of Use)
Log file (35.85 KB, text/plain)
2019-08-20 05:43 UTC, Oz Dror
no flags Details

Description Oz Dror 2019-08-20 05:43:18 UTC
Created attachment 1605968 [details]
Log file

Description of problem: When using OVMF guest BIOS, The Virtio Ethernet driver and other drivers including the balloon and the Serial driver failed to be activate at boot because Windows cannot verify the Driver signatures (code 52)

The issue does not occurs with no OVMF bios.



Version-Release number of selected component (if applicable):

Windows 10 version: Windows 10 pro 1903

Host OS: Ubuntu 19.10
Qemu version: 3.1.0
Virtio-win version: 0.1.171


How reproducible:
Every time. If I disable the driver verification in windows 10. the issue goes away.

Comment 2 Yvugenfi@redhat.com 2019-08-20 09:18:48 UTC
Hi,

Do you have secure boot enabled?

Thanks,
Yan.

Comment 3 Oz Dror 2019-08-20 13:56:32 UTC
Yes secure boot is enabled

Comment 4 Oz Dror 2019-08-20 16:56:29 UTC
So where do you find the RHEL WHQL virtio drivers

Comment 5 Oz Dror 2019-08-20 23:15:16 UTC
I have disabled secure boot, and now it is working.  The problem is that I need to have secure boot this w10 machine is for work. Without secure boot I might not be able to use it. 

Thanks

Comment 6 lijin 2019-08-21 00:56:13 UTC
This is a dup of bz1666705, if secure boot is enabled, msft signed drivers are required.

For redhat customers, they can get the whql signed drivers via redhat subscription.
For upstream users, "disable the driver verification" could be a workaround.

Yan, what's your opinion?

Comment 7 Yvugenfi@redhat.com 2019-08-21 12:21:03 UTC
(In reply to lijin from comment #6)
> This is a dup of bz1666705, if secure boot is enabled, msft signed drivers
> are required.
> 
> For redhat customers, they can get the whql signed drivers via redhat
> subscription.
> For upstream users, "disable the driver verification" could be a workaround.
> 
> Yan, what's your opinion?

We are discussing internally the option to provide upstream users with attestation signed drivers.

Comment 8 Oz Dror 2019-08-21 13:17:14 UTC
When should I check if it becomes available.

Thanks

Comment 9 Yvugenfi@redhat.com 2019-08-21 13:27:59 UTC
Oz, I suggest to be in touch towards beginning of September regarding the decisions.

Comment 10 Oz Dror 2019-09-23 02:01:28 UTC
Hi any news regarding the availability of  whql virtio driver. Thanks

Comment 11 Oz Dror 2019-09-23 02:02:18 UTC
Hi any news regarding the availability of  whql virtio driver. Thanks

Comment 12 Amnon Ilan 2019-10-12 13:47:29 UTC
(In reply to Oz Dror from comment #11)
> Hi any news regarding the availability of  whql virtio driver. Thanks

We will not provide the attestation signed drivers upstream in the near future

Are you a Red Hat customer? then you can get the whqled drivers. 
Otherwise, you can try to whql the drivers with MSFT on your own (with your device ids)

Comment 14 Amnon Ilan 2019-12-30 11:03:17 UTC
Closing as wontfix. Feel free to comment


Note You need to log in before you can comment on or make changes to this bug.