RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1672541 - virtio-win drivers build with Visual Studio 2017
Summary: virtio-win drivers build with Visual Studio 2017
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.1
Hardware: x86_64
OS: Windows
medium
medium
Target Milestone: rc
: ---
Assignee: ybendito
QA Contact: lijin
URL:
Whiteboard:
Depends On:
Blocks: 1691990 1725380
TreeView+ depends on / blocked
 
Reported: 2019-02-05 09:56 UTC by ybendito
Modified: 2019-07-30 14:22 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1691990 (view as bug list)
Environment:
Last Closed: 2019-07-30 14:22:06 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
black-screen (12.68 KB, image/png)
2019-02-12 01:50 UTC, xiagao 		no flags Details
Driver1 for test on ARM64 (3.03 MB, application/octet-stream)
2019-02-14 07:21 UTC, ybendito 		no flags Details
device manager screenshot (62.02 KB, image/png)
2019-03-06 04:36 UTC, xiagao 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1997 0 None None None 2019-07-30 14:22:45 UTC

Description ybendito 2019-02-05 09:56:57 UTC 
Description of problem:

virtio-win is moving to build the drivers using Visual Studio 2017.
The main motivation is to build also ARM64 drivers, but the change affects all the drivers built also for regular Windows operating systems.

This BZ is for tracking of testing progress of the drivers after transition.

Additional info:
Comment 1 ybendito 2019-02-05 10:01:50 UTC 
virtio-win build 164

https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=838960

built from Yuri's arm64 branch with VS 2017

This build is mostly experimental, to give a try to new VS2017 brew
build VM and build RH-signed ARM64 binaries (in addition to traditional
x86 and amd64)
Comment 2 ybendito 2019-02-05 10:05:23 UTC 
We'd like QE feedback regarding possibility of smoke test for the drivers.
P1: netkvm / viostor / vioscsi (x64)
P2: other (x64/x86)
Comment 4 pmsjt 2019-02-06 18:20:24 UTC 
Hi ybendito

I just did a quick smoke test with ARM64's viostor and netkvm.

viostor seems to be working fine, in the very small test. I just mounted a volume with viostor and accessed some files. I have not yet performed any heavy operation, like booting the entire OS from it.

netkvm bugchecks immediately upon install.

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED


0xFFFFFFFF80000002
0xFFFFDC80C098B00C
0xFFFFC38A3C8E9D30
0xFFFFC38A3C8E9930

I'll try to get a proper stack trace for you later.
Comment 5 pmsjt 2019-02-08 10:12:12 UTC 
Looks like we have a data access alignment problem in the code. I doubt this is cause by your work to enable VS2017, but this needs to be fixed if the driver is to ever work under ARM.

ExceptionAddress: ffff9c81aa8b600c
   ExceptionCode: 80000002 (Data misaligned)
  ExceptionFlags: 00000000
NumberParameters: 0

In lack of symbols, this is the best I can do:

0d fffffd01`5f4351d0 fffff803`d7e2b10c netkvm+0x18d28
0e fffffd01`5f4351d0 fffff803`d7e251e0 netkvm+0xb10c
0f fffffd01`5f4351e0 fffff803`d7e25a48 netkvm+0x51e0
10 fffffd01`5f435280 fffff803`d7e31f94 netkvm+0x5a48
11 fffffd01`5f4352c0 fffff803`dd9a316c netkvm+0x11f94
12 fffffd01`5f435450 fffff803`dd9cb1fc ndis!ndisMInvokeInitialize+0x9c
13 fffffd01`5f4354b0 fffff803`dd8e5548 ndis!ndisMInitializeAdapter+0x4f4
14 fffffd01`5f435b30 fffff803`dd8e56f4 ndis!ndisInitializeAdapter+0x90
15 fffffd01`5f435ba0 fffff803`dd8f0514 ndis!ndisPnPStartDevice+0x9c
16 fffffd01`5f435c10 fffff803`dd8f0450 ndis!ndisStartDeviceSynchronous+0x74
17 fffffd01`5f435c70 fffff803`d9a38b50 ndis!ndisStartDeviceWorkItem+0x30
18 fffffd01`5f435ca0 fffff803`d9af4170 nt!ExpWorkerThread+0x1c0
19 fffffd01`5f435d30 fffff803`d9a080d8 nt!PspSystemThreadStartup+0x60
1a fffffd01`5f435d90 00000000`00000000 nt!KiStartSystemThread+0x20

netkvm+0x18d28:
fffff803`d7e38d28 f81f8149 stur        x9,[x10,#-8]
0: kd> r x10
Last set context:
x10=ffff9c81aa8b6014

So, the problem is that we are trying to read an 8-byte quantity from a 4-byte-alligned address. This won't do on ARM.
Comment 6 pmsjt 2019-02-08 11:03:19 UTC 
I just realized the drivers are actually included in the package as well. Sorry for the extra message.


netkvm!virtqueue_add_buf+0x48 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\virtio\virtioring.c @ 92] 
netkvm!CVirtQueue::AddBuf+0x18 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-virtqueue.h @ 204] 
netkvm!CParaNdisRX::AddRxBufferToQueue+0x4c [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-rx.cpp @ 142] 
netkvm!CParaNdisRX::PrepareReceiveBuffers+0x60 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-rx.cpp @ 57] 
netkvm!CParaNdisRX::Create+0xa0 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-rx.cpp @ 37] 
netkvm!ParaNdis_VirtIONetInit+0x430 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-common.cpp @ 1164] 
netkvm!ParaNdis_FinishInitialization+0x98 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-common.cpp @ 1305] 
netkvm!ParaNdis6_Initialize+0x774 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\wlh\parandis6-driver.cpp @ 361] 
ndis!ndisMInvokeInitialize+0x9c
ndis!ndisMInitializeAdapter+0x4f4
ndis!ndisInitializeAdapter+0x90
ndis!ndisPnPStartDevice+0x9c
ndis!ndisStartDeviceSynchronous+0x74
ndis!ndisStartDeviceWorkItem+0x30
nt!ExpWorkerThread+0x1c0
nt!PspSystemThreadStartup+0x60
nt!KiStartSystemThread+0x20
Comment 8 xiagao 2019-02-11 08:44:20 UTC 
Our test is not finished yet,but I would like to raise one issue first. Some automation test case failed with "ERROR: Shell command failed: u'type E:\\vioscsi\\w10\\x86\\vioscsi.inf | findstr DriverVer='    (status: 1,    output: u'\n')"

I checked all driver's inf file for win10-32 guest and found there is one blank space after 'DriverVer'.

old version:
DriverVer=12/10/2018,63.77.104.16300
the latest version
DriverVer = 02/02/2019,63.77.104.16400


Will we leave the blank space after 'DriverVer' later, if yes, we will modify our automation script.
Comment 9 ybendito 2019-02-11 10:36:28 UTC 
(In reply to xiagao from comment #8)
> Our test is not finished yet,but I would like to raise one issue first. Some
> automation test case failed with "ERROR: Shell command failed: u'type
> E:\\vioscsi\\w10\\x86\\vioscsi.inf | findstr DriverVer='    (status: 1,   
> output: u'\n')"
> 
> I checked all driver's inf file for win10-32 guest and found there is one
> blank space after 'DriverVer'.
> 
> old version:
> DriverVer=12/10/2018,63.77.104.16300
> the latest version
> DriverVer = 02/02/2019,63.77.104.16400
> 
> 
> Will we leave the blank space after 'DriverVer' later, if yes, we will
> modify our automation script.

Unfortunately it is looks like updated stampinf tool populates the line with these spaces. IMO, better to adjust the script to be more tolerant.
Comment 10 xiagao 2019-02-12 01:50:58 UTC 
Created attachment 1533860 [details]
black-screen

Win2008-64 and Win2008-r2 hit black screen during installation, the detailed info is:
file: \Windows\system32\drivers\vioscsi.sys
status: 0xc0000428
info: windows cannot verify the digital signature for this file.
Comment 11 Vadim Rozenfeld 2019-02-12 02:07:22 UTC 
(In reply to xiagao from comment #10)
> Created attachment 1533860 [details]
> black-screen
> 
> Win2008-64 and Win2008-r2 hit black screen during installation, the detailed
> info is:
> file: \Windows\system32\drivers\vioscsi.sys
> status: 0xc0000428
> info: windows cannot verify the digital signature for this file.

Do you see the same problem with viostor?

Thanks,
Vadim.
Comment 12 xiagao 2019-02-12 03:28:10 UTC 
(In reply to Vadim Rozenfeld from comment #11)
> (In reply to xiagao from comment #10)
> > Created attachment 1533860 [details]
> > black-screen
> > 
> > Win2008-64 and Win2008-r2 hit black screen during installation, the detailed
> > info is:
> > file: \Windows\system32\drivers\vioscsi.sys
> > status: 0xc0000428
> > info: windows cannot verify the digital signature for this file.
> 
> Do you see the same problem with viostor?
> 
> Thanks,
> Vadim

Test with win200864 guest manually, can't load viostor and vioscsi driver during os installation.
Comment 13 pmsjt 2019-02-12 03:34:14 UTC 
I also experienced the same error in ARM64 but assumed the signature was a test one. So I added "testsigned=true" to both {bootmgr} and {default} and setup "bootdebug" and "debug" also on {bootmgr} and {default} and the system boots fine that way.
Comment 14 pmsjt 2019-02-12 03:42:32 UTC 
If I enable testsigning and KD, the system boots but I still get this message showing in the debugger:

Windows Boot Debugger Kernel Version 18836 UP Free ARM 64-bit (AArch64)
Machine Name:
Primary image base = 0x00000000`407cc000 Loaded module list = 0x00000000`40960b28
System Uptime: not available
*** Windows is unable to verify the signature of
    the file \Windows\System32\drivers\viostor.sys.  It will be allowed to load
    because the boot debugger is enabled.
Comment 15 xiagao 2019-02-12 07:44:16 UTC 
Run acceptance test which includes critical test cases, hit two issues.

1. as comment 12, can't load viostor and vioscsi driver during os installation for win2008-64/r2 guest
2. there is no digital signer for all drivers for win2008-32.
Comment 17 ybendito 2019-02-14 07:21:06 UTC 
Created attachment 1534682 [details]
Driver1 for test on ARM64
Comment 18 ybendito 2019-02-14 07:24:06 UTC 
(In reply to pmsjt from comment #6)
> netkvm!virtqueue_add_buf+0x48
> [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-
> windows\virtio\virtioring.c @ 92] 
> netkvm!CVirtQueue::AddBuf+0x18

I've fixed the misalignment, May I ask to check the driver in attachment 1534682 [details]?
Comment 19 pmsjt 2019-02-14 22:45:23 UTC 
(In reply to ybendito from comment #18)
> (In reply to pmsjt from comment #6)
> > netkvm!virtqueue_add_buf+0x48
> > [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-
> > windows\virtio\virtioring.c @ 92] 
> > netkvm!CVirtQueue::AddBuf+0x18
> 
> I've fixed the misalignment, May I ask to check the driver in attachment
> 1534682 [details]?

Hi ybendito.

I just tested the new driver. Indeed the unaligned problem seems to have gone away. However the system is still crashing. This time with a DPC watchdog bugcheck


 # Child-SP          RetAddr           Call Site
00 fffff802`5c012650 fffff802`5d085a48 nt!KeAccumulateTicks+0x166ab0
01 (Inline Function) --------`-------- nt!KiUpdateRunTime+0x58
02 (Inline Function) --------`-------- nt!KiUpdateTime+0xcc0
03 fffff802`5c0126c0 fffff802`5d9a2dd4 nt!KeClockInterruptNotify+0xec8
04 (Inline Function) --------`-------- hal!HalpTimerClockInterruptEpilogCommon+0x18
05 (Inline Function) --------`-------- hal!HalpTimerClockInterruptCommon+0xf0
06 fffff802`5c012e20 fffff802`5d03a688 hal!HalpTimerClockInterrupt+0x104
07 (Inline Function) --------`-------- nt!KiCallInterruptServiceRoutine+0xa4
08 (Inline Function) --------`-------- nt!KiRunIsr+0x3d8
09 fffff802`5c012e70 fffff802`5d008044 nt!KiPlayInterrupt+0x950
0a fffff802`5c012ff0 fffff802`5d09cd34 nt!KxSwitchStackAndPlayInterrupt+0x1c
0b ffffc284`f28fa590 fffff802`5d09cc4c nt!KiSwitchStackAndPlayInterrupt+0x5c
0c (Inline Function) --------`-------- nt!KiProcessInterrupt+0xb4
0d ffffc284`f28fa5c0 fffff802`5d0030dc nt!KiInterruptException+0xc4
0e ffffc284`f28fa610 fffff802`5d9a2bd8 nt!KiKernelSp0InterruptHandler+0x5c
0f ffffc284`f28fa980 fffff802`5d9a289c hal!HalpGitQueryCounter+0x28
10 (Inline Function) --------`-------- hal!HalpTimerStallExecutionProcessor+0x14c
11 ffffc284`f28fa990 fffff802`5eaf8a14 hal!KeStallExecutionProcessor+0x24c
12 ffffc284`f28faa20 fffff802`5eaf71e4 netkvm!CParaNdisCX::SendControlMessage+0x2cc
13 ffffc284`f28faae0 fffff802`5eaf73f4 netkvm!ParaNdis_DeviceFiltersUpdateRxMode+0x6c
14 ffffc284`f28fab10 fffff802`5eaf93e4 netkvm!ParaNdis_UpdateDeviceFilters+0x1c
15 ffffc284`f28fab40 fffff802`5eb05e9c netkvm!ParaNdis_OnSetPacketFilter+0x84
16 ffffc284`f28fab70 fffff802`623e31f0 netkvm!ParaNdis6_OidRequest+0x26c
17 ffffc284`f28fac30 fffff802`62346130 ndis!ndisMInvokeOidRequest+0x268
18 ffffc284`f28facb0 fffff802`6234d840 ndis!ndisMDoOidRequest+0x368
19 ffffc284`f28fad60 fffff802`6232e510 ndis!ndisQueueOidRequest+0x1f8
1a ffffc284`f28fadb0 fffff802`62852080 ndis!NdisFOidRequest+0x110
1b ffffc284`f28fae80 fffff802`6235df28 wfplwfs!LwfLowerOidRequest+0x80
1c ffffc284`f28faeb0 fffff802`623453bc ndis!ndisFInvokeOidRequest+0xa8
1d ffffc284`f28faf30 fffff802`5d0c4430 ndis!ndisFDoOidRequestInternal+0x1ec
1e ffffc284`f28fb000 fffff802`62345188 nt!KeExpandKernelStackAndCalloutInternal+0x80
1f (Inline Function) --------`-------- ndis!ndisExpandStack+0x28
20 ffffc284`f28fb060 fffff802`6234d7cc ndis!ndisFDoOidRequest+0x38
21 ffffc284`f28fb090 fffff802`6232e510 ndis!ndisQueueOidRequest+0x184
22 ffffc284`f28fb0e0 fffff805`bf231960 ndis!NdisFOidRequest+0x110
23 ffffc284`f28fb1b0 fffff802`6235df28 pacer!PcFilterRequest+0x80
24 ffffc284`f28fb1f0 fffff802`623453bc ndis!ndisFInvokeOidRequest+0xa8
25 ffffc284`f28fb270 fffff802`5d0c4430 ndis!ndisFDoOidRequestInternal+0x1ec
26 ffffc284`f28fb340 fffff802`62345188 nt!KeExpandKernelStackAndCalloutInternal+0x80
27 (Inline Function) --------`-------- ndis!ndisExpandStack+0x28
28 ffffc284`f28fb3a0 fffff802`6234d7cc ndis!ndisFDoOidRequest+0x38
29 ffffc284`f28fb3d0 fffff802`6234647c ndis!ndisQueueOidRequest+0x184
2a ffffc284`f28fb420 fffff802`6232ede8 ndis!ndisMOidRequest+0x1ec
2b ffffc284`f28fb4d0 fffff802`62597920 ndis!NdisOidRequest+0x68
2c ffffc284`f28fb510 fffff802`625975e8 tcpip!FlpNdisRequestUnderReference+0xb0
2d ffffc284`f28fb680 fffff802`6259913c tcpip!FlpOpenAdapterComplete+0x100
2e ffffc284`f28fb720 fffff802`623e25d0 tcpip!FlBindAdapter+0x28c
2f ffffc284`f28fb7a0 fffff802`623ed264 ndis!ndisInvokeBindAdapter+0x78
30 ffffc284`f28fb7e0 fffff802`623eccb4 ndis!ndisBindNdis6Protocol+0x4d4
31 ffffc284`f28fba40 fffff802`623f0ce4 ndis!ndisBindProtocol+0x7c
32 ffffc284`f28fba90 fffff802`623ee798 ndis!Ndis::BindEngine::Iterate+0x504
33 ffffc284`f28fbc00 fffff802`623f75b8 ndis!Ndis::BindEngine::UpdateBindings+0xa8
34 ffffc284`f28fbc60 fffff802`5d032f90 ndis!Ndis::BindEngine::UpdateBindingsWorkItem+0x48
35 ffffc284`f28fbca0 fffff802`5d0abb88 nt!ExpWorkerThread+0x1b0
36 ffffc284`f28fbd30 fffff802`5d0080d8 nt!PspSystemThreadStartup+0x58
37 ffffc284`f28fbd90 00000000`00000000 nt!KiStartSystemThread+0x20
Comment 20 ybendito 2019-02-20 11:28:02 UTC 
(In reply to pmsjt from comment #19)
> (In reply to ybendito from comment #18)
> > (In reply to pmsjt from comment #6)
> > > netkvm!virtqueue_add_buf+0x48
> > > [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-
> > > windows\virtio\virtioring.c @ 92] 
> > > netkvm!CVirtQueue::AddBuf+0x18
> > 
> > I've fixed the misalignment, May I ask to check the driver in attachment
> > 1534682 [details]?
> 
> Hi ybendito.
> 
> I just tested the new driver. Indeed the unaligned problem seems to have
> gone away. However the system is still crashing. This time with a DPC
> watchdog bugcheck
> 

Thank you for the test. It looks like the problem now is that the driver does not
receive the response from QEMU on command via control queue. Next build of
drivers (soon) will contain workaround for this DPC watchdog, but it will not
fix the root cause of the problem, I think.
I suggest to take all ARM64 issues out of this BZ (as this is not a regression)
for stabilization to https://github.com/virtio-win/kvm-guest-drivers-windows/issues/177
Comment 21 xiagao 2019-02-28 09:09:15 UTC 
Hit the same issue as comment 15 for virtio-win-prewhql-0.1-166.
Comment 22 xiagao 2019-03-06 04:36:54 UTC 
Created attachment 1541222 [details]
device manager screenshot

Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for Win2008-32/64 guests.
Comment 23 Vadim Rozenfeld 2019-03-07 11:05:05 UTC 
(In reply to xiagao from comment #22)
> Created attachment 1541222 [details]
> device manager screenshot
> 
> Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for
> Win2008-32/64 guests.

Thanks,
Let me check this issue. Is it only Win2008 drivers problem or other drivers
also have th esame problem?

Vadim.
Comment 24 xiagao 2019-03-08 01:07:10 UTC 
(In reply to Vadim Rozenfeld from comment #23)
> (In reply to xiagao from comment #22)
> > Created attachment 1541222 [details]
> > device manager screenshot
> > 
> > Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for
> > Win2008-32/64 guests.
> 
> Thanks,
> Let me check this issue. Is it only Win2008 drivers problem or other drivers
> also have th esame problem?
> 
> Vadim.

Test Win2019,Win2016,Win10-32,Win8-32,Win2012r2,Win7-32,Win2008r2,Win2008-32/64, only Win2008-32/64 guest hit this issue.
Comment 25 Vadim Rozenfeld 2019-03-08 03:45:21 UTC 
(In reply to xiagao from comment #24)
> (In reply to Vadim Rozenfeld from comment #23)
> > (In reply to xiagao from comment #22)
> > > Created attachment 1541222 [details]
> > > device manager screenshot
> > > 
> > > Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for
> > > Win2008-32/64 guests.
> > 
> > Thanks,
> > Let me check this issue. Is it only Win2008 drivers problem or other drivers
> > also have th esame problem?
> > 
> > Vadim.
> 
> Test
> Win2019,Win2016,Win10-32,Win8-32,Win2012r2,Win7-32,Win2008r2,Win2008-32/64,
> only Win2008-32/64 guest hit this issue.

Can you please check WinXP and WS2003 where it is possible?

Thanks,
Vadim.
Comment 26 xiagao 2019-03-11 07:28:35 UTC 
(In reply to Vadim Rozenfeld from comment #25)
> (In reply to xiagao from comment #24)
> > (In reply to Vadim Rozenfeld from comment #23)
> > > (In reply to xiagao from comment #22)
> > > > Created attachment 1541222 [details]
> > > > device manager screenshot
> > > > 
> > > > Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for
> > > > Win2008-32/64 guests.
> > > 
> > > Thanks,
> > > Let me check this issue. Is it only Win2008 drivers problem or other drivers
> > > also have th esame problem?
> > > 
> > > Vadim.
> > 
> > Test
> > Win2019,Win2016,Win10-32,Win8-32,Win2012r2,Win7-32,Win2008r2,Win2008-32/64,
> > only Win2008-32/64 guest hit this issue.
> 
> Can you please check WinXP and WS2003 where it is possible?
> 
> Thanks,
> Vadim.

Drivers for WinXP and WS2003 are no digitally signed,either.
Comment 27 Vadim Rozenfeld 2019-03-12 10:07:43 UTC 
(In reply to xiagao from comment #26)
> (In reply to Vadim Rozenfeld from comment #25)
> > (In reply to xiagao from comment #24)
> > > (In reply to Vadim Rozenfeld from comment #23)
> > > > (In reply to xiagao from comment #22)
> > > > > Created attachment 1541222 [details]
> > > > > device manager screenshot
> > > > > 
> > > > > Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for
> > > > > Win2008-32/64 guests.
> > > > 
> > > > Thanks,
> > > > Let me check this issue. Is it only Win2008 drivers problem or other drivers
> > > > also have th esame problem?
> > > > 
> > > > Vadim.
> > > 
> > > Test
> > > Win2019,Win2016,Win10-32,Win8-32,Win2012r2,Win7-32,Win2008r2,Win2008-32/64,
> > > only Win2008-32/64 guest hit this issue.
> > 
> > Can you please check WinXP and WS2003 where it is possible?
> > 
> > Thanks,
> > Vadim.
> 
> Drivers for WinXP and WS2003 are no digitally signed,either.


Thanks. 
Can we give a try to build 169 https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=860127
I tried WS 2008 SP1 but it works as expected (no signature problems).

Thanks,
Vadim.
Comment 28 pmsjt 2019-03-13 06:01:40 UTC 
(In reply to Vadim Rozenfeld from comment #27)
> (In reply to xiagao from comment #26)
> > (In reply to Vadim Rozenfeld from comment #25)
> > > (In reply to xiagao from comment #24)
> > > > (In reply to Vadim Rozenfeld from comment #23)
> > > > > (In reply to xiagao from comment #22)
> > > > > > Created attachment 1541222 [details]
> > > > > > device manager screenshot
> > > > > > 
> > > > > > Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for
> > > > > > Win2008-32/64 guests.
> > > > > 
> > > > > Thanks,
> > > > > Let me check this issue. Is it only Win2008 drivers problem or other drivers
> > > > > also have th esame problem?
> > > > > 
> > > > > Vadim.
> > > > 
> > > > Test
> > > > Win2019,Win2016,Win10-32,Win8-32,Win2012r2,Win7-32,Win2008r2,Win2008-32/64,
> > > > only Win2008-32/64 guest hit this issue.
> > > 
> > > Can you please check WinXP and WS2003 where it is possible?
> > > 
> > > Thanks,
> > > Vadim.
> > 
> > Drivers for WinXP and WS2003 are no digitally signed,either.
> 
> 
> Thanks. 
> Can we give a try to build 169
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=860127
> I tried WS 2008 SP1 but it works as expected (no signature problems).
> 
> Thanks,
> Vadim.

Is it just me, or brewweb.engineering.redhat.com has been inaccessible for a while now?
Comment 29 lijin 2019-03-13 06:15:15 UTC 
(In reply to pmsjt from comment #28)
> 
> Is it just me, or brewweb.engineering.redhat.com has been inaccessible for a
> while now?

It works for me now :-)
Comment 30 lijin 2019-03-13 06:59:56 UTC 
(In reply to Vadim Rozenfeld from comment #27)

> Thanks. 
> Can we give a try to build 169
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=860127
> I tried WS 2008 SP1 but it works as expected (no signature problems).


Hi Vadim,

build 169 behaves the same.

There seems sth wrong with the chain of the trusted certificate. 
And this issue disappear after I install related certificates before driver install:
Now the chain of trusted certificate is as following:
Digicer Assured ID Root CA
 - Digicer Assured ID Code Signing CA-1
   - Red Hat,Inc

I export them from a working vm(win2k8R2), then install them on win2008, and then install the driver, drivers are signed.
But there is a little difference: the signer is "red hat,inc" instead of "Red Hat, Inc".
I'm not sure if it's related to the certificate I export.
Comment 31 Vadim Rozenfeld 2019-03-13 10:02:06 UTC 
(In reply to pmsjt from comment #28)
> (In reply to Vadim Rozenfeld from comment #27)
> > (In reply to xiagao from comment #26)
> > > (In reply to Vadim Rozenfeld from comment #25)
> > > > (In reply to xiagao from comment #24)
> > > > > (In reply to Vadim Rozenfeld from comment #23)
> > > > > > (In reply to xiagao from comment #22)
> > > > > > > Created attachment 1541222 [details]
> > > > > > > device manager screenshot
> > > > > > > 
> > > > > > > Test virtio-win-prewhql-0.1-168, all drivers are no digitally signed for
> > > > > > > Win2008-32/64 guests.
> > > > > > 
> > > > > > Thanks,
> > > > > > Let me check this issue. Is it only Win2008 drivers problem or other drivers
> > > > > > also have th esame problem?
> > > > > > 
> > > > > > Vadim.
> > > > > 
> > > > > Test
> > > > > Win2019,Win2016,Win10-32,Win8-32,Win2012r2,Win7-32,Win2008r2,Win2008-32/64,
> > > > > only Win2008-32/64 guest hit this issue.
> > > > 
> > > > Can you please check WinXP and WS2003 where it is possible?
> > > > 
> > > > Thanks,
> > > > Vadim.
> > > 
> > > Drivers for WinXP and WS2003 are no digitally signed,either.
> > 
> > 
> > Thanks. 
> > Can we give a try to build 169
> > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=860127
> > I tried WS 2008 SP1 but it works as expected (no signature problems).
> > 
> > Thanks,
> > Vadim.
> 
> Is it just me, or brewweb.engineering.redhat.com has been inaccessible for a
> while now?

Unfortunately brewweb.engineering.redhat.com is not accessible from outside of RH domain.
We can make it public through fedoraproject after some quick checking.  

Sorry for any inconvenience,
Vadim.
Comment 32 Vadim Rozenfeld 2019-03-13 10:17:01 UTC 
(In reply to lijin from comment #30)
> (In reply to Vadim Rozenfeld from comment #27)
> 
> > Thanks. 
> > Can we give a try to build 169
> > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=860127
> > I tried WS 2008 SP1 but it works as expected (no signature problems).
> 
> 
> Hi Vadim,
> 
> build 169 behaves the same.
> 
> There seems sth wrong with the chain of the trusted certificate. 
> And this issue disappear after I install related certificates before driver
> install:
> Now the chain of trusted certificate is as following:
> Digicer Assured ID Root CA
>  - Digicer Assured ID Code Signing CA-1
>    - Red Hat,Inc
> 
> I export them from a working vm(win2k8R2), then install them on win2008, and
> then install the driver, drivers are signed.
> But there is a little difference: the signer is "red hat,inc" instead of
> "Red Hat, Inc".
> I'm not sure if it's related to the certificate I export.

It has to be "Red Hat, Inc"

This is how we sigh the drivers:
        "$SIGTOOL" sign /sha1 $SHA1_Thumprint /s my /n "Red Hat, Inc" \
          /ac "$(cygpath -wa $spec_dir/DigiCert_Assured_ID_Root_CA.crt)" \
          /fd sha1 /t "http://timestamp.digicert.com" /v "$(cygpath -wa $file)"

and this is how output from "certutil -store -user my" looks like:
Subject: CN=Red Hat, Inc, O=Red Hat, Inc, L=Raleigh, S=nc, C=US
Comment 34 lijin 2019-03-21 06:08:26 UTC 
(In reply to Vadim Rozenfeld from comment #32)
> (In reply to lijin from comment #30)
> > (In reply to Vadim Rozenfeld from comment #27)
> > 
> > > Thanks. 
> > > Can we give a try to build 169
> > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=860127
> > > I tried WS 2008 SP1 but it works as expected (no signature problems).
> > 
> > 
> > Hi Vadim,
> > 
> > build 169 behaves the same.
> > 
> > There seems sth wrong with the chain of the trusted certificate. 
> > And this issue disappear after I install related certificates before driver
> > install:
> > Now the chain of trusted certificate is as following:
> > Digicer Assured ID Root CA
> >  - Digicer Assured ID Code Signing CA-1
> >    - Red Hat,Inc
> > 
> > I export them from a working vm(win2k8R2), then install them on win2008, and
> > then install the driver, drivers are signed.
> > But there is a little difference: the signer is "red hat,inc" instead of
> > "Red Hat, Inc".
> > I'm not sure if it's related to the certificate I export.
> 
> It has to be "Red Hat, Inc"
> 
> This is how we sigh the drivers:
>         "$SIGTOOL" sign /sha1 $SHA1_Thumprint /s my /n "Red Hat, Inc" \
>           /ac "$(cygpath -wa $spec_dir/DigiCert_Assured_ID_Root_CA.crt)" \
>           /fd sha1 /t "http://timestamp.digicert.com" /v "$(cygpath -wa
> $file)"
> 
> and this is how output from "certutil -store -user my" looks like:
> Subject: CN=Red Hat, Inc, O=Red Hat, Inc, L=Raleigh, S=nc, C=US

I try again on win2008sp2-64:
1.Install a new image and load netkvm&vioscsi driver during guest installation, after installation both netkvm and scsi driver are not signed;
2.Then I install balloon driver and click "always trust software from "Red Hat,Inc""(this will install the redhat.cer to the guest), then reboot guest;
3.I find that netkvm&scsi drivers are signed by "Red Hat,Inc", but balloon driver is signed by "red hat,inc"
4.Uninstall netkvm driver and reinstall it, netkvm is signed by "red hat,inc" as well.

I don't know what happened :-(

btw, in my understanding, win2008 and win7/2008R2 use same certificate file while win8+ use another one, right?
I'm asking this as we need to update the file in QE's automation tools.
Thanks
Comment 35 Vadim Rozenfeld 2019-03-21 10:31:09 UTC 
(In reply to lijin from comment #34)
> (In reply to Vadim Rozenfeld from comment #32)
> > (In reply to lijin from comment #30)
> > > (In reply to Vadim Rozenfeld from comment #27)
> > > 
> > > > Thanks. 
> > > > Can we give a try to build 169
> > > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=860127
> > > > I tried WS 2008 SP1 but it works as expected (no signature problems).
> > > 
> > > 
> > > Hi Vadim,
> > > 
> > > build 169 behaves the same.
> > > 
> > > There seems sth wrong with the chain of the trusted certificate. 
> > > And this issue disappear after I install related certificates before driver
> > > install:
> > > Now the chain of trusted certificate is as following:
> > > Digicer Assured ID Root CA
> > >  - Digicer Assured ID Code Signing CA-1
> > >    - Red Hat,Inc
> > > 
> > > I export them from a working vm(win2k8R2), then install them on win2008, and
> > > then install the driver, drivers are signed.
> > > But there is a little difference: the signer is "red hat,inc" instead of
> > > "Red Hat, Inc".
> > > I'm not sure if it's related to the certificate I export.
> > 
> > It has to be "Red Hat, Inc"
> > 
> > This is how we sigh the drivers:
> >         "$SIGTOOL" sign /sha1 $SHA1_Thumprint /s my /n "Red Hat, Inc" \
> >           /ac "$(cygpath -wa $spec_dir/DigiCert_Assured_ID_Root_CA.crt)" \
> >           /fd sha1 /t "http://timestamp.digicert.com" /v "$(cygpath -wa
> > $file)"
> > 
> > and this is how output from "certutil -store -user my" looks like:
> > Subject: CN=Red Hat, Inc, O=Red Hat, Inc, L=Raleigh, S=nc, C=US
> 
> I try again on win2008sp2-64:
> 1.Install a new image and load netkvm&vioscsi driver during guest
> installation, after installation both netkvm and scsi driver are not signed;
> 2.Then I install balloon driver and click "always trust software from "Red
> Hat,Inc""(this will install the redhat.cer to the guest), then reboot guest;
> 3.I find that netkvm&scsi drivers are signed by "Red Hat,Inc", but balloon
> driver is signed by "red hat,inc"
> 4.Uninstall netkvm driver and reinstall it, netkvm is signed by "red
> hat,inc" as well.
> 
> I don't know what happened :-(
> 

That sounds very strange. I will try to investigate this issue.

> btw, in my understanding, win2008 and win7/2008R2 use same certificate file
> while win8+ use another one, right?

That's true. Win7 and earlier virsions (WXp, WNet,WLh) are signied with SHA1 
cert, issued by Digicer, while Win8 and later are signed with SHA256 issued by Verisign.

 

> I'm asking this as we need to update the file in QE's automation tools.
> Thanks
Comment 39 lijin 2019-05-15 00:40:16 UTC 
Change status to verified according to comment#37 and comment#38
Comment 41 errata-xmlrpc 2019-07-30 14:22:06 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1997
Note You need to log in before you can comment on or make changes to this bug.