Original discussion - https://github.com/coreos/fedora-coreos-tracker/issues/1119 We made the broad decision to change the metadata of the vSphere artifacts in the following ways: - change osType to reflect it is a RHEL 8 operating system - change hw version to 15 https://github.com/openshift/os/pull/748/ - change the firmware to use EFI by default https://github.com/coreos/coreos-assembler/pull/2762 - change the firwmare to have SecureBoot enabled by default https://github.com/coreos/coreos-assembler/pull/2767/ Defaulting to having SecureBoot enabled by default is the most impactful change and we failed to communicate this change more broadly. We are in a position where enabling this for new cluster installs may prevent customers + partners from installing out-of-tree kernel modules as part of the day 1 use case. PM has indicated that the majority of the OCP ecosystem is not ready for this kind of broad change and we should default to having SecureBoot disabled.
Slack thread that started this discussion - https://coreos.slack.com/archives/C999USB0D/p1657552645787859 Since Slack can be ephemeral, capturing some of the more important info: ``` Taylor Smith 1 hour ago Hi team - can someone help give me more information about https://github.com/coreos/coreos-assembler/pull/2767 ? I know vsphere is going to default with the vsphere csi driver- so I see how that might be related to this? Portworx/Pure Storage is, from my understanding, needing to install kernel modules which, unless signed, they will be blocked from doing so in these vsphere configuration. I need help understanding how non-vsphere csi drivers, who don't have signed kmods, can be utilized? If it's not that easy of a question and will be unique with every CSI partner, I can set up a call with the portworx contact to figure out this particular case. Thanks so much. Micah Abbott 1 hour ago cc @marrusl this seems like it should be on your radar Colin Walters 1 hour ago Perhaps for IPI we could offer an option to disable secure boot; UPI can do so manually today too. Micah Abbott 1 hour ago Users should be able to disable SecureBoot on the VMs from the vSphere console after install, too Colin Walters 36 minutes ago Yeah, though that's not a "reprovisionable" approach and also doesn't work with auto-scaling; but I'm sure it's also scriptable via an API, so presumably it can be done after-the fact for IPI too even with some manual rebooting Taylor Smith 20 minutes ago Let me know if there's any helpful information I can provide for this convo. Micah Abbott 16 minutes ago back channel conversations with mark is indicating that the broader OCP ecosystem is not ready for SB enabled by default; we'll likely have to revert that change for 4.11 - https://bugzilla.redhat.com/show_bug.cgi?id=2106055 Taylor Smith 14 minutes ago Perfect, thank you! I'll track the BZ. ```
This bug has been reported fixed in a new RHCOS build and is ready for QE verification. To mark the bug verified, set the Verified field to Tested. This bug will automatically move to MODIFIED once the fix has landed in a new bootimage.
Fix has landed in RHCOS 412.86.202207142104-0. To verify, download the RHCOS OVA. tar xvf rhcos*ova cat coreos.ovf | grep -i secure The value should be set to false
Pre-verify passed with RHCOS 412.86.202207142104-0 [coreos-assembler]$ tar xvf rhcos-412.86.202207142104-0-vmware.x86_64.ova coreos.ovf disk.vmdk [coreos-assembler]$ cat coreos.ovf | grep -i secure <vmw:Config ovf:required="false" vmw:key="bootOptions.efiSecureBootEnabled" vmw:value="false"/>
The fix for this bug has landed in a bootimage bump, as tracked in bug 2106061 (now in status MODIFIED). Moving this bug to MODIFIED.
Verify passed with RHCOS 412.86.202207191738-0 [coreos-assembler]$ tar xvf rhcos-412.86.202207191738-0-vmware.x86_64.ova coreos.ovf disk.vmdk [coreos-assembler]$ cat coreos.ovf | grep -i secure <vmw:Config ovf:required="false" vmw:key="bootOptions.efiSecureBootEnabled" vmw:value="false"/>
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 (Moderate: OpenShift Container Platform 4.12.0 bug fix and security update), 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/RHSA-2022:7399