Bug 1443351
Summary: | [svvp][ovmf] job "Secure Boot Logo Test" failed with q35&ovmf | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | lijin <lijin> |
Component: | ovmf | Assignee: | Laszlo Ersek <lersek> |
Status: | CLOSED ERRATA | QA Contact: | FuXiangChun <xfu> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 7.4 | CC: | areis, chayang, jinzhao, juzhang, lersek, lijin, lprosek, michen, vrozenfe, xfu, yvugenfi |
Target Milestone: | rc | ||
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-08-01 22:22:15 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: | |||
Bug Blocks: | 1443361 | ||
Attachments: |
Description
lijin
2017-04-19 06:57:35 UTC
This is almost certainly a duplicate of bug 1443361 (thanks Amnon for the See Also reference). Note that the MSDN article at [1] does not mention DBX at all. Let me go through the listed test cases one by one: > Before you run the test, Secure Boot option should be in the default shipping > (out-of-box) configuration, specifically: > Secure Boot option must be ON. should be OK > Microsoft Keys are in Key-Exchange key (KEK) and signature database (db). * EnrollDefaultKeys.efi adds "Microsoft Corporation KEK CA 2011", with SHA1 31:59:0b:fd:89:c9:d7:4e:d0:87:df:ac:66:33:4b:39:31:25:4b:30, to the KEK. * EnrollDefaultKeys.efi also adds: - "Microsoft Windows Production PCA 2011" (58:0a:6f:4c:c4:e4:b6:69:b9:eb:dc:1b:2b:3e:08:7b:80:d0:67:8d), and - "Microsoft Corporation UEFI CA 2011" (46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3) to "db", so this should be covered. > No Microsoft test keys are allowed in the Public Key (PK), KEK or > signature database. Should be OK as well. ... However, judging from the names of the individual test cases: > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent This is the same as in bug 1443361. > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxVerifyMicrosoftKEKpresent See above near "Microsoft Corporation KEK CA 2011", I guess. > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmMicrosoftSignatureInDB See above near "Microsoft Windows Production PCA 2011" and "Microsoft Corporation UEFI CA 2011", I guess. > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxVerifyRevocationSignatures No clue what contents this one looks for, in the "dbx" variable. > Microsoft.UefiSecureBootLogo.Tests. > Confirm64KilobytesOfUnauthenticatedVariableStorage Sorry, this won't work. OVMF's entire variable store is smaller than 64KB (it provides 56 KB), and this test case (based on its name at least) wants 64KB just for unauthenticated variables. I have zero clue where this requirement comes from; to me it looks arbitrary. > Microsoft.UefiSecureBootLogo.Tests.ConfirmSetOfLargeVariable I guess this is a variant of the previous test. After windows update,there is one more sub-test failed: Microsoft.UefiSecureBootLogo.Tests.VerifyBootServicesVariableBehavior: Error 4/25/2017 2:07:39.661 PM AreNotEqual(0, 0) - After ExitBootServices(), attempting to call GetVariable() on an existing variable with attributes "NV,BS" should fail. (In reply to lijin from comment #12) > After windows update,there is one more sub-test failed: > Microsoft.UefiSecureBootLogo.Tests.VerifyBootServicesVariableBehavior: > Error 4/25/2017 2:07:39.661 PM AreNotEqual(0, 0) - After ExitBootServices(), > attempting to call GetVariable() on an existing variable with attributes > "NV,BS" should fail. The statement in the error message is correct, and OVMF should indeed work like that. Too bad that the error message doesn't bother to *name* the actual darn variable (and variable namespace GUID) that were used for the check! It is interesting that this test only failed after Windows Update. Are MS actively developing SVVP test cases? In that case, it's a pretty safe assumption that some of the new test cases could be buggy. (This is a constant problem with all test suites, not just SVVP.) To my knowledge, the variable driver stack in edk2 (and used by OVMF) implements "boot time only" variables correctly. If not, that's a generic edk2 failure then that has to be fixed (and Intel will be happy to receive the issue report), but again, we need to know the actual variable namespace and name used for the test. Re: comment 12 and comment 13: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/1238a44d-1deb-44b3-86aa-2b112b754161/secure-boot-logo-test-verifybootservicesvariablebehavior-failure "After configuring and enabling Secure Boot, did you perform a Windows restart? If you did not, then please restart Windows ("shutdown /r") and re-run the test. If you did, this is a firmware bug. It existed in older builds of Tiano Core and the EDK/UDK." So this should really work now. Perhaps the test fails because some other SB-related test fail earlier. (In reply to Laszlo Ersek from comment #14) > Re: comment 12 and comment 13: > > https://social.msdn.microsoft.com/Forums/sqlserver/en-US/1238a44d-1deb-44b3- > 86aa-2b112b754161/secure-boot-logo-test-verifybootservicesvariablebehavior- > failure > > "After configuring and enabling Secure Boot, did you perform a Windows > restart? If you did not, then please restart Windows ("shutdown /r") and > re-run the test. If you did, this is a firmware bug. It existed in older > builds of Tiano Core and the EDK/UDK." I tried after guest reboot; > So this should really work now. Perhaps the test fails because some other > SB-related test fail earlier. And I also ran this job on a fresh installed latest 2016(en_windows_server_2016_x64_dvd_9718492.iso),still hit this error. I managed to run the Secure Boot Logo Test myself, and I'm seeing the reported failures. The test output / logs that are generated are actually helpful, it's just that this tool seems to make everything possible to *hide* the useful bits of information (namely, the actual test executable's messages) in a heap of garbage. I find the "hlkx" format (see the attachment on comment 0) entirely useless / unpenetrable as well. Here's the only method I found to read the useful messages: (1) After running the test, navigate to Results | ... | Run Test | Logs | Te.wtl (2) Double click "Te.wtl". The HCK Manager comes up. The trick is that the test results are recorded in a large XML file, and the HCK Manager offers several XSLT files to process the XML into HTML, for display. These options are listed under "View", near the top left corner, and in my experience, every option except for "Complete" is fully useless, because they all hide the actual test executable messages. So ignore every option here, just stick with Complete. (3) Once the HTML-like view is rendered (which is still extremely hard to navigate in this viewer thing), right-click on the report anywhere, and select View Source from the context menu. A Notepad window will open with the generated HTML source in it. Now we are making progress! (4) Still using notepad, save the HTML file to some comfortable location. (5) Transfer the saved HTML file from the guest to the host. The tool used for this can be anything at all, I prefer Cygwin + scp. (6) On the host, open the HTML file with firefox, and search it for the string "Result:". This will jump from test-end to test-end, immediately showing the verdict. In case of failure, it is very easy to scroll up a little bit, and see (a) the test name, and (b) the actual complaints that the test executable emitted. Those messages are the *only* useful parts of the entire humongous report, and they are in fact detailed and helpful. They might even allow developers to fix errors. I'll analyze the report in more detail later. Created attachment 1274808 [details] complete report in HTML format, exported as described in comment 20 I saw some different result from your HTML format report: 1.you use "Windows Server 2016 Standard" and we use "Windows Server 2016 Datacenter"; We should test svvp with datacenter 2.Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent This sub-test passed from your side ,but we failed I don't know if it's due to datacenter issue or sth,but we'd like to see it's passed. Did you do some extra operation before the test? Could you paste your qemu command here?Maybe I can try with similar cli to see if it can pass from my side. Thanks 3.Microsoft.UefiSecureBootLogo.Tests.OutOfBoxVerifyRevocationSignatures I don't find this sub-test from your report 4.Microsoft.UefiSecureBootLogo.Tests.OutOfBoxAllowCorrectlySignedSetVariable this sub-test failed from our side,but you failed 5.Following four errors are similar: Microsoft.UefiSecureBootLogo.Tests.OutOfBoxVerifyMicrosoftKEKpresent Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmMicrosoftSignatureInDB Microsoft.UefiSecureBootLogo.Tests.Confirm64KilobytesOfUnauthenticatedVariableStorage Microsoft.UefiSecureBootLogo.Tests.ConfirmSetOfLargeVariable (In reply to lijin from comment #22) > I saw some different result from your HTML format report: > 1.you use "Windows Server 2016 Standard" and we use "Windows Server 2016 > Datacenter"; > We should test svvp with datacenter See, this is the kind of information I should have *before* I spend several hours on setting up a new guest. For now, Standard will have to do on my side. I'll use it for local development and testing. > 2.Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent > This sub-test passed from your side ,but we failed > I don't know if it's due to datacenter issue or sth,but we'd like to see > it's passed. I agree, it should pass. Since it fails on your side, please attach the report for it, in the format I described in comment 20. > Did you do some extra operation before the test? > Could you paste your qemu command here?Maybe I can try with similar cli to > see if it can pass from my side. > Thanks I don't use the raw QEMU command line, I exclusively rely on libvirt for testing. Anyway, I don't think it's up to a command line difference; hopefully we'll know more after you please attach your results (in the rendered HTML format, with the test executable's messages). > 3.Microsoft.UefiSecureBootLogo.Tests.OutOfBoxVerifyRevocationSignatures > I don't find this sub-test from your report Right, not sure why. I used the latest HCK filters as instructed in <https://github.com/daynix/VirtHCK/wiki>, maybe that makes a difference. Perhaps they removed the test case. > > 4.Microsoft.UefiSecureBootLogo.Tests.OutOfBoxAllowCorrectlySignedSetVariable > this sub-test failed from our side,but you failed No clue why it failed for me. I'll retry later with a fresh variable store. > > 5.Following four errors are similar: > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxVerifyMicrosoftKEKpresent > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmMicrosoftSignatureInDB > Microsoft.UefiSecureBootLogo.Tests. > Confirm64KilobytesOfUnauthenticatedVariableStorage > Microsoft.UefiSecureBootLogo.Tests.ConfirmSetOfLargeVariable Right, the most important ones (that are urgent to fix) are: - Confirm64KilobytesOfUnauthenticatedVariableStorage - ConfirmSetOfLargeVariable Thanks. (In reply to Laszlo Ersek from comment #21) > Created attachment 1274808 [details] > complete report in HTML format, exported as described in comment 20 So here's my analysis / extracts for the failed cases: (1) OutOfBoxVerifyMicrosoftKEKpresent The relevant tool messages are: > Parsing signatureList 1 > Parsing signatureList 2 > IsGreaterThanOrEqual(2, 1) - "KEK": At least 1 signature present. > Searching for Microsoft signatureOwners... > Found Non-Microsoft signatureOwner = d5c1df0b-1bac-4edf-ba48-08834009ca5a > Found Non-Microsoft signatureOwner = d5c1df0b-1bac-4edf-ba48-08834009ca5a > IsGreaterThanOrEqual(0, 1) - "KEK": At least 1 Microsoft-owned signature > present. This test case iterates over the X509 certificate entries in the KEK, and checks the OwnerGUID value associated with each of them. From the two certs that EnrollDefaultKeys.efi puts in the KEK, one is "Microsoft Corporation KEK CA 2011". The issue is that EnrollDefaultKeys.efi uses its own FILE_GUID (through gEfiCallerIdGuid), namely D5C1DF0B-1BAC-4EDF-BA48-08834009CA5A, as SignatureOwner for it: > Status = EnrollListOfX509Certs ( > EFI_KEY_EXCHANGE_KEY_NAME, > &gEfiGlobalVariableGuid, > RedHatPkKek1, sizeof RedHatPkKek1, &gEfiCallerIdGuid, > MicrosoftKEK, sizeof MicrosoftKEK, &gEfiCallerIdGuid, <--- HERE > NULL); According to the UEFI specification 2.6, "30.4.1 Signature Database": > SignatureOwner -- An identifier which identifies the agent which added the > signature to the list. > > [...] > > Each signature has an owner SignatureOwner, which is a GUID identifying > the agent which inserted the signature in the database. Agents might > include the operating system or an OEM- supplied driver or application. > Agents may examine this field to understand whether they should manage the > signature or not. And then in "30.5.3 Signature Database Update": > 9. [...] The algorithm by which an agent decides which signatures may be > safely removed is agent-specific. In most cases, agents should not remove > signatures where the SignatureOwner field is not the agent's. [...] Since EnrollDefaultKeys.efi is the agent that enrolls the MS cert in question into KEK, it is *obviously* correct to use its FILE_GUID as SignatureOwner. SignatureOwner does not stand for the issuer of the certificate or anything like that, it stands for the program that puts the cert in place. Either way, this test bug should not be hard to work around, as the log from comment 20 has hints elsewhere what the expected SignatureOwner GUID is. Namely, in the output of "Confirm64KilobytesOfUnauthenticatedVariableStorage", we see: > Microsoft variables under VendorGuid > {77fa9abd-0359-4d32-bd60-28f4e78f784b}: 17 bytes By googling the GUID, the following results confirm the idea: https://blog.uncooperative.org/blog/2014/10/23/uefi-security-databases/ > [...] 77fa9abd-0359-4d32-bd60-28f4e78f784b , which is the GUID Microsoft > uses to identify themselves [...] https://firmware.intel.com/messages/219 > The Microsoft DB entries are specific to Microsoft Windows 8. The GUID > associated with these certificates is 77fa9abd-0359-4d32-bd60-28f4e78f784b http://blog.fpmurphy.com/2012/11/list-secure-boot-certificates.html > Type: X509 (GUID: 77FA9ABD-0359-4D32-BD60-28F4E78F784B) > ... > Subject: CN=US ST=Washington L=Redmond O=Microsoft Corporation > CN=Microsoft Corporation KEK CA 2011 So, for this, the expected fix is to add the GUID in question as a static variable to EnrollDefaultKeys.efi, and use it in the call quoted above. (2) OutOfBoxConfirmMicrosoftSignatureInDB Messages: > Parsing signatureList 1 > Parsing signatureList 2 > IsGreaterThanOrEqual(2, 1) - "db": At least 1 signature present. > Searching for Microsoft signatureOwners... > Found Non-Microsoft signatureOwner = d5c1df0b-1bac-4edf-ba48-08834009ca5a > Found Non-Microsoft signatureOwner = d5c1df0b-1bac-4edf-ba48-08834009ca5a > IsGreaterThanOrEqual(0, 1) - "db": At least 1 Microsoft-owned signature > present. The code from EnrollDefaultKeys.efi: > Status = EnrollListOfX509Certs ( > EFI_IMAGE_SECURITY_DATABASE, > &gEfiImageSecurityDatabaseGuid, > MicrosoftPCA, sizeof MicrosoftPCA, &gEfiCallerIdGuid, > MicrosoftUefiCA, sizeof MicrosoftUefiCA, &gEfiCallerIdGuid, > NULL); So this is the exact same issue as (1) in comment 24, just for "db", not "KEK", and should be fixable similarly. (3) Confirm64KilobytesOfUnauthenticatedVariableStorage Messages: > NOTE: if this testcase fails, try restarting the machine and then running > this test case on its own, for example: "te.exe UefiSecureBootLogo.dll > /name:Microsoft.UefiSecureBootLogo.Tests.Confirm64KilobytesOfUnauthenticatedVariableStorage" > > Initializing HighResolutionTimer - 100000000 Hz > > Computing bytes to test... Variable space consumed by PK, KEK, db, & dbx: > 10379 bytes > > Calculating the size of variables within the Microsoft Secure Boot > namespace... > > Offset 000002B0 Next 000002C8 > Offset 00000604 Next 00000620 > Microsoft variables under VendorGuid > {77fa9abd-0359-4d32-bd60-28f4e78f784b}: 17 bytes > Total bytes consumed: 10396 > Kilobytes to test: 43 OK, so the idea is apparently: measure how much varstore is used already, genuinely, and then add enough stuff temporarily so that the varstore usage peaks at ~64KB? But, the actual sum doesn't seem to be 64KB. It's 10379 B + 43 KB ~= 53 KB. Where does that target come from? OVMF's live area in the varstore is 56 KB, so this is a similar number, but I don't know how Windows can know about it, plus the test name says "64 Kilobytes". The log goes on -- we manage to create 14 variables, each 1KB in size: > Deleting variables from prior test runs. Creating 43 1kB variables. > > AreEqual(7, 7) - testKilobyte1: Attributes from GetVariable() match > SetVariable() > > AreEqual(1024, 1024) - testKilobyte1: DataSize from GetVariable() matches > SetVariable() > > AreEqual(7, 7) - testKilobyte2: Attributes from GetVariable() match > SetVariable() > > AreEqual(1024, 1024) - testKilobyte2: DataSize from GetVariable() matches > SetVariable() > > ... AreEqual(7, 7) - testKilobyte14: Attributes from GetVariable() match > SetVariable() > > AreEqual(1024, 1024) - testKilobyte14: DataSize from GetVariable() matches > SetVariable() And then we run out of space: > Test creation of testKilobyte15 Insufficient Variable Storage - > SetVariable failed with status 0xC0000454 > STATUS_INSUFFICIENT_NVRAM_RESOURCES (EFI_OUT_OF_RESOURCES) Try rebooting > your system to allow the firmware to reclaim unused space. The test should > pass on its first execution after a reboot. If this error appears on the > first test execution after a reboot, your firmware has a bug. VariableName > "testKilobyte15" VendorGuid 77fa9abd-0359-4d32-bd60-28f4e78f784b > Attributes 0x00000007 DataSize 0x00000400 > > Failure to create 43kB of variables. Could only successfully create 14kB > for a total of 25kB This does look like a fragmentation issue. OVMF (and other, generic parts of BDS) do some heavy variable munging on each boot. The variable driver has a function called ReclaimForOS() [MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c], called at Ready-To-Boot. (The reclaim attempt could be moved to an earlier point, by setting PcdReclaimVariableSpaceAtEndOfDxe, but that would be worse, actually -- QemuBootOrderLib massages the Boot#### variables way later than we signal End-Of-Dxe. So Ready-To-Boot is definitely the best spot to call ReclaimForOS().) ReclaimForOS() employs the following logic: > // > // Check if the free area is below a threshold. > // > if (((RemainingCommonRuntimeVariableSpace < mVariableModuleGlobal->MaxVariableSize) || > (RemainingCommonRuntimeVariableSpace < mVariableModuleGlobal->MaxAuthVariableSize)) || > ((PcdGet32 (PcdHwErrStorageSize) != 0) && > (RemainingHwErrVariableSpace < PcdGet32 (PcdMaxHardwareErrorVariableSize)))){ > Status = Reclaim ( > mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase, > &mVariableModuleGlobal->NonVolatileLastVariableOffset, > FALSE, > NULL, > NULL, > 0 > ); > ASSERT_EFI_ERROR (Status); > } OVMF currently sets the limits like this: > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000 > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800 (8KB and 10KB, respectively). The first limit comes from: > commit fd4ba547a13a4e3ddfb820de59887875bf86c5de > Author: Jordan Justen <jordan.l.justen> > Date: Fri Jun 14 21:37:44 2013 +0000 > > OvmfPkg: Reduce PcdMaxVariableSize with secure boot to avoid assert > > r14252 causes OVMF to crash if SECURE_BOOT_ENABLE is set, > because PcdMaxVariableSize is set to a larger value than > required. In other platforms, 0x2000 seems to be sufficient. > > Reported-by: Gary Ching-Pang Lin <glin> > Signed-off-by: Jordan Justen <jordan.l.justen> > Reviewed-by: Laszlo Ersek <lersek> > Tested-by: Laszlo Ersek <lersek> The second limit comes from: > commit f5404a3eba1d3bae54e6b02be0a87f8f471eb732 > Author: James Bottomley <James.Bottomley> > Date: Thu Mar 24 21:38:41 2016 -0400 > > OvmfPkg: Increase the maximum size for Authenticated variables > > During real world testing I was getting an error with too many entries > in db: On my Secure boot laptop, I currently have seven certificates: > two Microsoft ones, Three Kernel ones from various distributions, my > own Secure Key and a temporary test key. That gives a total EFI > Signature List size of 8317 which is over the 0x2000 maximum. > > Fix this by setting the PcdMaxAuthVariableSize to 0x2800 (10K) which > isn't much of an increase but allows for 9-10 certificates. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: James Bottomley <James.Bottomley> > Regression-tested-by: Laszlo Ersek <lersek> > Reviewed-by: Laszlo Ersek <lersek> > Reviewed-by: Star Zeng <star.zeng> And the limit checking in ReclaimForOS() goes back to the following commits: - 0c18794ea428 ("Add security package to repository.", 2011-09-02) - 952ba83c4781 ("SecurityPkg Variable: Implement variable quota management.", 2015-01-27) - 13af4ab06516 ("SecurityPkg Variable: Support the new introduced PcdMaxAuthVariableSize.", 2015-06-10) The variable quota management looks a bit suspicious, but OVMF inherits 0 values for PcdMaxUserNvVariableSpaceSize and PcdBoottimeReservedNvVariableSpaceSize, so quota management is disabled. To me, neither making the limit checking logic more aggressive, nor raising the limits for the current checking, look attractive. Regarding the latter, we even had to *lower* PcdMaxAuthVariableSize in commit fd4ba547a13a (see above). And regarding the former (-> more frequent reclaims on OS boots), I don't want Reclaim() to be called more frequently. Reclaim() has a visible boot performance impact. I'll have to experiment with this; I think I'll start with enlarging the varstore. (4) ConfirmSetOfLargeVariable Messages: > NOTE: if this testcase fails, try restarting the machine and then running > this test case on its own, for example: "te.exe UefiSecureBootLogo.dll > /name:Microsoft.UefiSecureBootLogo.Tests.ConfirmSetOfLargeVariable" > > Test creation of 1 large variable of size 32768 bytes. > > Test creation of testLargeVariable Unexpected Error - SetVariable failed > with status 0xC000000D VariableName "testLargeVariable" VendorGuid > 77fa9abd-0359-4d32-bd60-28f4e78f784b Attributes 0x00000007 DataSize > 0x00008000 This has a direct root cause, and perhaps a less direct one as well. The direct cause is: > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000 from commit fd4ba547a13a ("OvmfPkg: Reduce PcdMaxVariableSize with secure boot to avoid assert", 2013-06-14). The indirect cause is that, similarly to case (3) in comment 26, we simply might not have enough contiguous room in the varstore. Enlarging the varstore should eliminate the indirect cause, and also enable us to bump PcdMaxVariableSize (and then PcdMaxAuthVariableSize too) to 0x8000 -- the issue described in commit fd4ba547a13a should no longer hit against a larger varstore. (5) OutOfBoxAllowCorrectlySignedSetVariable Messages: > Unexpected Powershell Exception: > System.Management.Automation.CmdletInvocationException: Unexpected Result, > status error: 0xC0000454 ---> > Microsoft.SecureBoot.Commands.StatusException: Unexpected Result, status > error: 0xC0000454 at > System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord > errorRecord) --- End of inner exception stack trace --- at > System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable > input) at > System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace > rs, Boolean performSyncInvoke) at > System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace > rsToUse, Boolean isSync) at > System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 > input, PSDataCollection`1 output, PSInvocationSettings settings) at > System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 > input, PSDataCollection`1 output, PSInvocationSettings settings) at > System.Management.Automation.PowerShell.Invoke(IEnumerable input, > PSInvocationSettings settings) at > Microsoft.UefiSecureBootLogo.Tests.OutOfBoxAllowCorrectlySignedSetVariable() > > IsTrue - SetVariable() that appends using valid Out-of-Box AuthInfo should > succeed. Honestly, I have no clue what this is. I understand what the test is trying to do, but it says "Unexpected Powershell Exception", so maybe it doesn't even get as far as calling gRT->SetVariable()? I found other reports on the web: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3f6b2460-4edd-4acd-a078-77c579a73496/secure-boot-logo-test https://social.msdn.microsoft.com/Forums/en-US/868c4853-57a1-40f4-bf50-a31725173a80/whck-system-secure-boot-logo-test In the first report, MS indicates "OutOfBoxAllowCorrectlySignedSetVariable" may depend on "OutOfBoxVerifyMicrosoftKEKpresent" (see case (1) in comment 24): > if testcase "OutOfBoxVerifyMicrosoftKEKpresent" fails, then your system is > misconfigured. If "OutOfBoxVerifyMicrosoftKEKpresent" passes, then this > failure in "OutOfBoxAllowCorrectlySignedSetVariable" is a firmware bug So maybe if we fix that, this could work too. (In reply to lijin from comment #15) > (In reply to Laszlo Ersek from comment #14) > > Re: comment 12 and comment 13: > > > > https://social.msdn.microsoft.com/Forums/sqlserver/en-US/1238a44d-1deb-44b3- > > 86aa-2b112b754161/secure-boot-logo-test-verifybootservicesvariablebehavior- > > failure > > > > "After configuring and enabling Secure Boot, did you perform a Windows > > restart? If you did not, then please restart Windows ("shutdown /r") > > and re-run the test. If you did, this is a firmware bug. It existed in > > older builds of Tiano Core and the EDK/UDK." > > I tried after guest reboot; > > > So this should really work now. Perhaps the test fails because some > > other SB-related test fail earlier. > > And I also ran this job on a fresh installed latest > 2016(en_windows_server_2016_x64_dvd_9718492.iso),still hit this error. It is now confirmed that the VerifyBootServicesVariableBehavior test failure is due to a test bug / Windows bug: > Filter 19238 > > Version: 1 > > Expires on: 06/30/2017 17:00:00 > > Issue Description: The test case in question is attempting to > verify that UEFI variables with attributes BS (not RunTime) are > not visible/modifiable from within the OS. It assumes that > "CurrentPolicy" variable will be NV+BS. The recent Windows Update > to patch "Golden Key" changed the attribute of "CurrentPolicy" > from NV+BS to NV+BS+RT+AT. The WU change to a RunTime attribute > breaks the assumptions made by this test case. > > Issue Resolution: This is an acceptable failure Created attachment 1275172 [details]
Secure Boot Logo Test report (100% pass)
I have 100.00% Pass Rate for the Secure Boot Logo Test.
I'm soon going to post / attach patches.
Created attachment 1275191 [details] EnrollDefaultKeys.efi patches (for Fedora's & Gerd's pkgs) There are six patches: 1 6be3d53093cd OvmfPkg/EnrollDefaultKeys: update SignatureOwner GUID for Windows HCK 2 09096ead3078 OvmfPkg/EnrollDefaultKeys: expose CertType parameter of EnrollListOfCerts 3 8ca585b76148 OvmfPkg/EnrollDefaultKeys: blacklist empty file in dbx for Windows HCK 4 136d73d3a531 OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros 5 cb4efd58838c OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK 6 47c1fe8ada3a OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB The first three are for EnrollDefaultKeys.efi, and are therefore downstream only. I'm going to post their RHEL7 ports to rhvirt-patches soon, but for users of Fedora and Gerd's RPMs, I'm attaching them here. The patches apply to the Fedora "edk2" package, at dist-git commit ad70d15d1cad ("Ship ovmf-ia32 package (bz 1424722)", 2017-03-15). The last three patches are upstreamable; I'll post them to edk2-devel. (In reply to Laszlo Ersek from comment #31) > The first three are for EnrollDefaultKeys.efi, and are therefore downstream > only. I'm going to post their RHEL7 ports to rhvirt-patches soon, but for > users of Fedora and Gerd's RPMs, I'm attaching them here. The patches apply > to the Fedora "edk2" package, at dist-git commit ad70d15d1cad ("Ship > ovmf-ia32 package (bz 1424722)", 2017-03-15). NB, CRLF -> LF conversion might be necessary first. (In reply to Laszlo Ersek from comment #31) > > There are six patches: > > [...] > > The last three patches are upstreamable; I'll post them to edk2-devel. Subject: [edk2] [PATCH 0/3] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB tests, and for future proofing Message-Id: <20170429201500.18496-1-lersek> URL: https://lists.01.org/pipermail/edk2-devel/2017-April/010334.html Created attachment 1275464 [details] FD_SIZE_4MB patches (for Fedora's & Gerd's pkgs) (In reply to Laszlo Ersek from comment #33) > (In reply to Laszlo Ersek from comment #31) > > > > There are six patches: > > > > [...] > > > > The last three patches are upstreamable; I'll post them to edk2-devel. > > Subject: [edk2] [PATCH 0/3] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB > tests, and for future proofing > Message-Id: <20170429201500.18496-1-lersek> > URL: https://lists.01.org/pipermail/edk2-devel/2017-April/010334.html After a thorough discussion on edk2-devel (see also the May archive!), these patches (the direction of them) are not appropriate for upstream at this time. So I'm attaching them too. They apply to upstream edk2 at commit 65ed9d7ff55a ("StdLib: GCC 6 build fixes", 2017-04-26). Created attachment 1275847 [details] latest failed report - html format (In reply to Laszlo Ersek from comment #23) > (In reply to lijin from comment #22) > > I saw some different result from your HTML format report: > > 1.you use "Windows Server 2016 Standard" and we use "Windows Server 2016 > > Datacenter"; > > We should test svvp with datacenter > > See, this is the kind of information I should have *before* I spend several > hours on setting up a new guest. > > For now, Standard will have to do on my side. I'll use it for local > development and testing. > > > 2.Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent > > This sub-test passed from your side ,but we failed > > I don't know if it's due to datacenter issue or sth,but we'd like to see > > it's passed. > > I agree, it should pass. Since it fails on your side, please attach the > report for it, in the format I described in comment 20. Thanks. This is the latest failed test result Sorry, we have another misunderstanding here. It's my fault -- I apologize. When I said OutOfBoxConfirmDBXisPresent should pass I meant that I agree that the expectations of this test case for OVMF are valid I did not mean that I expect OVMF to pass this test case right now Please wait until we move this BZ to MODIFIED, and fill in the Fixed-in-Version field, before repeating the test. Thank you. Posted upstream v2: Subject: [PATCH v2 0/5] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB tests, and for future proofing Message-Id: <20170503213947.32290-1-lersek> URL: https://lists.01.org/pipermail/edk2-devel/2017-May/010423.html (In reply to Laszlo Ersek from comment #39) > Posted upstream v2: > Subject: [PATCH v2 0/5] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB tests, > and > for future proofing > Message-Id: <20170503213947.32290-1-lersek> > URL: https://lists.01.org/pipermail/edk2-devel/2017-May/010423.html These patches have been committed. They replace the (now obsolete) attachment added in comment 34. Commits to backport: 1 210270730c0e OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag 2 636cda51903b OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros 3 b24fca05751f OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK 4 88a30bbc0a3c OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB 5 bba8dfbec3bb OvmfPkg: make the 4MB flash size the default 6 6e49d01cfb43 Revert "OvmfPkg: make the 4MB flash size the default" 7 0c79471d6a98 OvmfPkg/PlatformPei: handle non-power-of-two spare size for emu variables Fix included in ovmf-20170228-5.gitc325e41585e3.el7 Job can pass with ovmf-20170228-5.gitc325e41585e3.el7 So this issue has been fix,thanks Created attachment 1279885 [details]
the passed job log
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-2017:2056 |