Bug 1443361
| Summary: | [svvp][ovmf] job "Secure Boot Manual Logo Test" failed with q35&ovmf [TestOnly] | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | lijin <lijin> | ||||||||||||
| Component: | ovmf | Assignee: | Laszlo Ersek <lersek> | ||||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | FuXiangChun <xfu> | ||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||
| Priority: | high | ||||||||||||||
| Version: | 7.4 | CC: | chayang, juzhang, lersek, lprosek, marcel, michen, mrezanin, vrozenfe | ||||||||||||
| Target Milestone: | rc | Keywords: | TestOnly | ||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | ovmf-20170228-5.gitc325e41585e3.el7 | Doc Type: | If docs needed, set a value | ||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2017-10-10 11:32:07 UTC | Type: | Bug | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Bug Depends On: | 1443351 | ||||||||||||||
| Bug Blocks: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
lijin
2017-04-19 07:19:05 UTC
Created attachment 1272511 [details]
win2016 svvp test logs under q35 and ovmf
Hi Laszlo, Can you please have a look? Any pointers would be welcomed. Thanks, Marcel I believe that it happens because of non MS-signed Red Hat VirtIO SCSI controller driver. As far as I remember for SVVP, in general, we have to use MS-signed drivers only. As well as for ovmf secure boot itself. Can QE try using a MS-signed driver instead and check how it works/ But apart from that problem, there are several other, not related to this problem, tests failed. (In reply to Vadim Rozenfeld from comment #3) > I believe that it happens because of non MS-signed Red Hat VirtIO SCSI > controller driver. As far as I remember for SVVP, in general, we have to use > MS-signed drivers only. As well as for ovmf secure boot itself. Can QE try > using a MS-signed driver instead and check how it works/ I did test with ms-signed drivers(virtio-win-1.9.0-3.el7.noarch) when run secure boot tests > But apart from that problem, there are several other, not related to this > problem, tests failed. (In reply to lijin from comment #4) > (In reply to Vadim Rozenfeld from comment #3) > > I believe that it happens because of non MS-signed Red Hat VirtIO SCSI > > controller driver. As far as I remember for SVVP, in general, we have to use > > MS-signed drivers only. As well as for ovmf secure boot itself. Can QE try > > using a MS-signed driver instead and check how it works/ > > I did test with ms-signed drivers(virtio-win-1.9.0-3.el7.noarch) when run > secure boot tests > > > > But apart from that problem, there are several other, not related to this > > problem, tests failed. Sorry , I didn't realized that there are mixed test results collected in the same report file. The signed drives check was from April 10. the first test that failed was Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent Message 4/19/2017 11:26:20.645 AM Reading UEFI Secure Boot variable "dbx"... WexTraceInfo ThreadId=1136 ProcessId=3996 TimeStamp=127059449177 LogSessionId=1 Error 4/19/2017 11:26:20.650 AM GetVariable(dbx) - Variable is currently undefined: 0xC0000100 WexTraceInfo ThreadId=1136 ProcessId=3996 TimeStamp=127059466422 LogSessionId=1 Problems with the Forbidden Signature Database? (In reply to Vadim Rozenfeld from comment #5) > (In reply to lijin from comment #4) > > (In reply to Vadim Rozenfeld from comment #3) > > > I believe that it happens because of non MS-signed Red Hat VirtIO SCSI > > > controller driver. As far as I remember for SVVP, in general, we have to use > > > MS-signed drivers only. As well as for ovmf secure boot itself. Can QE try > > > using a MS-signed driver instead and check how it works/ > > > > I did test with ms-signed drivers(virtio-win-1.9.0-3.el7.noarch) when run > > secure boot tests > > > > > > > But apart from that problem, there are several other, not related to this > > > problem, tests failed. > > Sorry , I didn't realized that there are mixed test results collected in the > same report file. The signed drives check was from April 10. > > > the first test that failed was > > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent > > Message 4/19/2017 11:26:20.645 AM Reading UEFI Secure Boot variable "dbx"... > WexTraceInfo ThreadId=1136 ProcessId=3996 TimeStamp=127059449177 > LogSessionId=1 > > Error 4/19/2017 11:26:20.650 AM GetVariable(dbx) - Variable is currently > undefined: 0xC0000100 WexTraceInfo ThreadId=1136 ProcessId=3996 > TimeStamp=127059466422 LogSessionId=1 > this error is present during job "Secure Boot Logo Test"(bz1443351) job "Secure Boot Manual Logo Test" does not hit it > > Problems with the Forbidden Signature Database? (CC Ladi due to superficially similar bug 1382641. I remember that in that bug some connections were pointed out between Secure Boot and driver signing.) Now, I lack the exact error that's being reported here. But, assuming the core symptoms are: > Error 4/19/2017 1:49:38.249 PM FAILED while applying mixedHash_5_SigList.bin > to DBX Database (from comment 0), and > the first test that failed was > > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent > Message 4/19/2017 11:26:20.645 AM Reading UEFI Secure Boot variable "dbx"... > WexTraceInfo ThreadId=1136 ProcessId=3996 TimeStamp=127059449177 > LogSessionId=1 > > Error 4/19/2017 11:26:20.650 AM GetVariable(dbx) - Variable is currently > undefined: 0xC0000100 WexTraceInfo ThreadId=1136 ProcessId=3996 > TimeStamp=127059466422 LogSessionId=1 (from comment 5), then the underlying cause is the lack of the "dbx" UEFI variable, which contains blacklisted certificates, and hashes of blacklisted UEFI binaries. Now, this variable is not required by the UEFI spec, to my understanding. I think it is wrong for the test case to expect that "dbx" exists. From <https://technet.microsoft.com/en-us/library/dn747883.aspx> [1]: > 1.4.3 Forbidden Signature Database (dbx) > [...] The Windows Hardware Certification Requirements state that a dbx must > be present, so any dummy value, such as the SHA-256 hash of 0, may be used as > a safe placeholder until such time as Microsoft begins delivering dbx > updates. I am baffled by this. The dbx presence requirement, and a "safe placeholder" element on the blacklist, such as the SHA-256 of 0, look inexplicable to me. From <https://blogs.technet.microsoft.com/jhoward/2013/11/01/hyper-v-generation-2-virtual-machines-part-6/> [2]: > In Hyper-V, the firmware for a virtual machine is always in user mode. PK > and KEK are pre-populated and cannot be changed. db and dbx are also > prepopulated, but can be changed. Ugh, what? KEK cannot be changed??? (But, I digres...) More interestingly, *what* do they pre-populate DBX with? ... Either way, I guess this is why Hyper-V doesn't trip up their own SVVP test. The UEFI forum publishes dbx (= blacklist) updates from time to time: http://www.uefi.org/revocationlistfile and Fedora 22+ includes an OS-level utility called "dbxtool" that can apply the update: https://fedoraproject.org/wiki/Changes/UEFISecureBootBlacklistUpdates I have no idea what Windows tool can be used to apply the dbx update. If there is such a tool, it should be invoked before starting the SVVP test. From references [1] and [2] above, my impression is that DBX updates are shipped as part of Windows Update. Is that correct? If so, can we run Windows Update before running SVVP? If there is *no* such tool for Windows (including Windows Update), then we're left with three alternatives: * virtio-win could provide a (very simple!) OS level utility, similar to Fedora's dbxtool. The user would have to download the update file from uefi.org, and then execute the utility, before starting SVVP. * Or I could write a small UEFI application that loaded the DBX update file from the EFI system partition, and added it to the DBX variable. This would have to be invoked manually from the UEFI shell, similarly to (and after) EnrollDefaultKeys.efi. The update file would have to be downloaded by the user from uefi.org (using Windows or Linux), and placed on the ESP first. * Or I could extend EnrollDefaultKeys.efi to add such a "placeholder" to "dbx" right off the bat. I guess this would be the most convenient solution for users. Semantically, it would be the worst, however. Apparently, this is what Microsoft recommends under [1]. If this is the preferred solution, I will need someone (from Microsoft) to define the exact data whose hash should be placed into "dbx". ("SHA-256 hash of 0", from [1], is ill-defined.) Thoughts? (In reply to Laszlo Ersek from comment #7) > (CC Ladi due to superficially similar bug 1382641. I remember that in that > bug some connections were pointed out between Secure Boot and driver > signing.) > > Now, I lack the exact error that's being reported here. But, assuming the > core symptoms are: > > > Error 4/19/2017 1:49:38.249 PM FAILED while applying mixedHash_5_SigList.bin > > to DBX Database Yes,this bug tracks this error,it's the error during job "Secure Boot Manual Logo Test" Following errors are not,following errors you mentioned are for job "Secure Boot Logo Test"(bz1443351),they are not the same job. The attached svvp logs include all svvp jobs,as their job names are similar,Vadim may check the wrong item. > (from comment 0), and > > > the first test that failed was > > > > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent > > > Message 4/19/2017 11:26:20.645 AM Reading UEFI Secure Boot variable "dbx"... > > WexTraceInfo ThreadId=1136 ProcessId=3996 TimeStamp=127059449177 > > LogSessionId=1 > > > > Error 4/19/2017 11:26:20.650 AM GetVariable(dbx) - Variable is currently > > undefined: 0xC0000100 WexTraceInfo ThreadId=1136 ProcessId=3996 > > TimeStamp=127059466422 LogSessionId=1 > > (from comment 5), then the underlying cause is the lack of the "dbx" UEFI > variable, which contains blacklisted certificates, and hashes of blacklisted > UEFI binaries. > > Now, this variable is not required by the UEFI spec, to my understanding. I > think it is wrong for the test case to expect that "dbx" exists. > > From <https://technet.microsoft.com/en-us/library/dn747883.aspx> [1]: > > > 1.4.3 Forbidden Signature Database (dbx) > > > [...] The Windows Hardware Certification Requirements state that a dbx must > > be present, so any dummy value, such as the SHA-256 hash of 0, may be used as > > a safe placeholder until such time as Microsoft begins delivering dbx > > updates. > > I am baffled by this. The dbx presence requirement, and a "safe placeholder" > element on the blacklist, such as the SHA-256 of 0, look inexplicable to me. > > From > <https://blogs.technet.microsoft.com/jhoward/2013/11/01/hyper-v-generation-2- > virtual-machines-part-6/> [2]: > > > In Hyper-V, the firmware for a virtual machine is always in user mode. PK > > and KEK are pre-populated and cannot be changed. db and dbx are also > > prepopulated, but can be changed. > > Ugh, what? KEK cannot be changed??? (But, I digres...) More interestingly, > *what* do they pre-populate DBX with? > > ... Either way, I guess this is why Hyper-V doesn't trip up their own SVVP > test. > > The UEFI forum publishes dbx (= blacklist) updates from time to time: > > http://www.uefi.org/revocationlistfile > > and Fedora 22+ includes an OS-level utility called "dbxtool" that can apply > the update: > > https://fedoraproject.org/wiki/Changes/UEFISecureBootBlacklistUpdates > > I have no idea what Windows tool can be used to apply the dbx update. If > there is such a tool, it should be invoked before starting the SVVP test. > > From references [1] and [2] above, my impression is that DBX updates are > shipped as part of Windows Update. Is that correct? If so, can we run > Windows Update before running SVVP? > > If there is *no* such tool for Windows (including Windows Update), then > we're left with three alternatives: > > * virtio-win could provide a (very simple!) OS level utility, similar to > Fedora's dbxtool. The user would have to download the update file from > uefi.org, and then execute the utility, before starting SVVP. > > * Or I could write a small UEFI application that loaded the DBX update file > from the EFI system partition, and added it to the DBX variable. This would > have to be invoked manually from the UEFI shell, similarly to (and after) > EnrollDefaultKeys.efi. The update file would have to be downloaded by the > user from uefi.org (using Windows or Linux), and placed on the ESP first. > > * Or I could extend EnrollDefaultKeys.efi to add such a "placeholder" to > "dbx" right off the bat. I guess this would be the most convenient solution > for users. Semantically, it would be the worst, however. Apparently, this is > what Microsoft recommends under [1]. If this is the preferred solution, I > will need someone (from Microsoft) to define the exact data whose hash > should be placed into "dbx". ("SHA-256 hash of 0", from [1], is ill-defined.) > > Thoughts? Anyway,I will try windows update first and rerun job "Secure Boot Logo Test",then update it in bz1443351 I have 100.00% Pass Rate for the Secure Boot Manual Logo Test. Given that I've had to write no additional patches beyond those that I've written for bug 1443351, I'm marking this BZ as ON_QA and TestOnly, and making it dependent on bug 1443351. I'm soon going to add further details below bug 1443351 comment 29. -*- For the record, I should capture some things I learned while working with the Secure Boot Manual Logo Test, given that I used libvirt for the test client VM (like for all of my other VMs): - Only the hard disk should be marked with <boot order='1'/>, no other drive needs to be marked with <boot order='N'/> (such as UFD#1, UFD#2, UFD#TEST). - It is best to set a 20 second boot delay for the VM: <domain type='kvm'> <os> <bootmenu enable='yes' timeout='20000'/> </os> <domain> - When the test explains that the next step is to boot UFD#1, UFD#2, or UFD#TEST after reboot, simply interrupt the above 20 sec boot delay after reboot. Then, go into the UEFI Boot Manager, and manually launch the USB drive that the instructions identified before the reboot. These boot attempts will fail or succeed (as required by the test), but ultimately the user is returned to the UEFI Boot Manager. - After this, simply select the Windows Boot Manager, to boot Windows again and continue the test. - This is a very long manual test and attention to detail is important. Created attachment 1275171 [details] Secure Boot Manual Logo Test report (100% pass) (In reply to Laszlo Ersek from comment #9) > I have 100.00% Pass Rate for the Secure Boot Manual Logo Test. Attaching the test report. (In reply to Laszlo Ersek from comment #9) > I have 100.00% Pass Rate for the Secure Boot Manual Logo Test. > > Given that I've had to write no additional patches beyond those that I've > written for bug 1443351, I'm marking this BZ as ON_QA and TestOnly, and > making it dependent on bug 1443351. I'm soon going to add further details > below bug 1443351 comment 29. > > -*- > > For the record, I should capture some things I learned while working with > the Secure Boot Manual Logo Test, given that I used libvirt for the test > client VM (like for all of my other VMs): > > - Only the hard disk should be marked with <boot order='1'/>, no other drive > needs to be marked with <boot order='N'/> (such as UFD#1, UFD#2, UFD#TEST). > > - It is best to set a 20 second boot delay for the VM: > > <domain type='kvm'> > <os> > <bootmenu enable='yes' timeout='20000'/> > </os> > <domain> > > - When the test explains that the next step is to boot UFD#1, UFD#2, or > UFD#TEST after reboot, simply interrupt the above 20 sec boot delay after > reboot. Then, go into the UEFI Boot Manager, and manually launch the USB > drive that the instructions identified before the reboot. These boot > attempts will fail or succeed (as required by the test), but ultimately the > user is returned to the UEFI Boot Manager. > > - After this, simply select the Windows Boot Manager, to boot Windows again > and continue the test. > > - This is a very long manual test and attention to detail is important. I tried several more times,every time it failed at "FAILED while applying mixedHash_5_SigList.bin to DBX Database" and the "Unexpected Powershell Exception" error. I've no clue what's the reason.I'll attach the report Created attachment 1275846 [details]
html report
Oh, I'm *very* sorry that my message in comment 9 was unclear! What I meant was, *With the patches that I wrote*, I have 100.00% Pass Rate for the Secure Boot Manual Logo Test. So, right now there is nothing for QE to retest in this BZ. As I mentioned in comment 9, I marked this BZ "TestOnly", and set it dependent on bug 1443351. Consequently, please only retest this issue once bug 1443351 is moved to MODIFIED. And, for testing this bug, please use the official Brew build that will be listed in the Fixed-In-Version field of bug 1443351, at that time. Thanks! This BZ can now be tested against "ovmf-20170228-5.gitc325e41585e3.el7". Thanks. Created attachment 1279895 [details]
"secure boot manual logo test" passed log
Job can pass with ovmf-20170228-5.gitc325e41585e3.el7,the attachment is the passed job log.
So this issue has been fixed,thanks a lot
|