| Summary: | Cannot generate BSOD crash dump with secure boot enabled | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ladi Prosek <lprosek> |
| Component: | virtio-win | Assignee: | Ladi Prosek <lprosek> |
| virtio-win sub component: | virtio-win-prewhql | QA Contact: | Virtualization Bugs <virt-bugs> |
| Status: | CLOSED CANTFIX | Docs Contact: | |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | areis, coli, hachen, jinzhao, lersek, lijin, lprosek, michen, vrozenfe, xfu |
| Version: | 7.4 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-02-15 10:36:00 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: | |
|
Description
Ladi Prosek
2016-10-07 09:47:20 UTC
This issue is hard to debug because secure boot and live kernel debugging are mutually exclusive. It is also not possible to easily use a debug/instrumented vioscsi/viostor driver as secure boot only allows Microsoft-signed drivers on 1607. (In reply to Ladi Prosek from comment #0) > 2. Enable secure boot > > Boot into UefiShell (UefiShell.iso is inserted in a virtual CD) and run: > EnrollDefaultKeys.efi > reset -s > > Then enable secure boot in OVMF setup program: > Device Manager -> Secure Boot Configuration Running "EnrollDefaultKeys.efi" and then rebooting the platform are sufficient. "Device Manager -> Secure Boot Configuration" is only necessary if you'd like to disable Secure Boot after it's been enabled, or you'd like to manually enroll or delete some certificates. Thanks! Laszlo (In reply to Laszlo Ersek from comment #3) > (In reply to Ladi Prosek from comment #0) > > > 2. Enable secure boot > > > > Boot into UefiShell (UefiShell.iso is inserted in a virtual CD) and run: > > EnrollDefaultKeys.efi > > reset -s > > > > Then enable secure boot in OVMF setup program: > > Device Manager -> Secure Boot Configuration > > Running "EnrollDefaultKeys.efi" and then rebooting the platform are > sufficient. "Device Manager -> Secure Boot Configuration" is only necessary > if you'd like to disable Secure Boot after it's been enabled, or you'd like > to manually enroll or delete some certificates. Thanks! I should really get into the habit of writing these steps down as I do them instead of trying to remember what I did last week.. It seems to work fine on Windows 10 1511 upgraded to 1607. This would suggest that it is related to the new driver signing requirements in clean-installed 1607 with secure boot enabled (ref: bug 1376048). Laszlo, given the state of support of OVMF in RHEL, would you be fine with moving this to 7.5? Thanks! I have retested three builds of Windows 10 64-bit 1607 14393.0 1607 14393.187 1607 14393.447 with OVMF and secure boot enabled and cannot reproduce this anymore. I had troubles installing the right viostor driver on the VM that I believe exhibited this bug back in October 2016. Only after I removed all prior versions from the driver store (Device Uninstall with "Delete the driver software for this device" checked) did the driver successfully load. So I would speculate that this was also causing the issue I saw earlier. The storage driver needs to be reloaded on BSOD and perhaps Windows wasn't finding the correct one for some reason. OK, mystery solved. Here's how it can be reproduced: 1) Install Windows with a Microsoft signed (WHQL) storage driver 2) In Device Manager update the driver to a Red Hat signed one 3) Reboot 4) Trigger BSOD Apparently the new signing policy has an exception for boot drivers. Windows boots even with a cross-signed driver, undocumented, as far as I can tell. This exception is not implemented on the BSOD code path though, so the driver fails to load there. Nothing for us to do here, closing. (In reply to Ladi Prosek from comment #1) > This issue is hard to debug because secure boot and live kernel debugging > are mutually exclusive. It is also not possible to easily use a > debug/instrumented vioscsi/viostor driver as secure boot only allows > Microsoft-signed drivers on 1607. Hi Ladi, May I confirm with you about the driver signature when secure boot enabled? Is the Microsoft-signed driver a must when secure boot enabled? I run windows 2016 under q35/ovmf recently,and found that redhat signed netkvm&balloon can not loaded correctly when do secure boot while blk&scsi driver can load well. Is this the drivers' issue or it's by design? (In reply to lijin from comment #21) > (In reply to Ladi Prosek from comment #1) > > This issue is hard to debug because secure boot and live kernel debugging > > are mutually exclusive. It is also not possible to easily use a > > debug/instrumented vioscsi/viostor driver as secure boot only allows > > Microsoft-signed drivers on 1607. Hi lijin, > Hi Ladi, > > May I confirm with you about the driver signature when secure boot enabled? > > Is the Microsoft-signed driver a must when secure boot enabled? Yes, that's the official message from Microsoft. More on this in bug 1376048. > I run windows 2016 under q35/ovmf recently,and found that redhat signed > netkvm&balloon can not loaded correctly when do secure boot while blk&scsi > driver can load well. That's in line with the observation made in this bug. Boot-critical drivers seem to load fine with secure boot even without a Microsoft signature. As far as I know this fact is undocumented. > Is this the drivers' issue or it's by design? Seems to be either a bug in the OS or a by-design behavior of the OS. It is unlikely that a driver issue would be causing it to load when it shouldn't. |