Support older OpenVMM logic for SECURE_BOOT

[mebersol]

Don't change the attributes on SECURE_BOOT until all deployed images have the ability to rewrite variable attributes.

[daprilik]

When does this mismatch occur? Is this servicing related? i.e: since servicing doesn't update the UEFI components in the context of the guest?

[mebersol]

When does this mismatch occur? Is this servicing related? i.e: since servicing doesn't update the UEFI components in the context of the guest?

If an OpenHCL with the current code creates an NVRAM store, and then an older OpenHCL (without my recent fix) that expects SECURE_BOOT to carry the NV attribute tries to open that store, it will fail because attributes mismatch.

[jstarks]

Why are volatile variables being persisted to the NVRAM store?

[jstarks]

(I think I asked this in another context and didn't see follow up to look for a response. Sorry if you answered this once already.)

[daprilik]

When does this mismatch occur? Is this servicing related? i.e: since servicing doesn't update the UEFI components in the context of the guest?

If an OpenHCL with the current code creates an NVRAM store, and then an older OpenHCL (without my recent fix) that expects SECURE_BOOT to carry the NV attribute tries to open that store, it will fail because attributes mismatch.

Talking offline, Mike pointed out that this scenario is currently possible in a variety of cases, both via runtime servicing (in downgrade scenarios), or offline migration of OpenHCL-based VMs from uplevel to downlevel versions.

I think this is a reasonable workaround to the issue at hand, though I'd be remiss not to once again express hesitation at this sort of precarious back-compat situation we keep finding ourselves in 😅

---

As for your comment @jstarks, I'll leave Mike to offer UEFI-internals / historical context that I don't have.

[mebersol]

(I think I asked this in another context and didn't see follow up to look for a response. Sorry if you answered this once already.)

yeah, see #157 (comment)

[jstarks]

yeah, see #157 (comment)

Thanks. Continuing that discussion here... how does real hardware work? I.e., how do these variables get set in Project Mu by default?

[mebersol]

yeah, see #157 (comment)

Thanks. Continuing that discussion here... how does real hardware work? I.e., how do these variables get set in Project Mu by default?

The answer is "it depends". In some cases, these get populated in firmware from other sources. In other cases, implementations ignore the spec (e.g. Sean was surprised the dbDefault was marked as volatile, it was done because it's the only way to say 'read-only'). I'd like to merge this now, and we have a plan for at least secure boot enablement going forward (will require changes to mu_msvmpkg first).