I agree with you that this function is extremely sensitive and important, and I kinda like your idea of splitting the protocol into a "policy" and "policy control", but I don't think it make practical sense to split them this way. At the very least, you end up with a chicken and egg problem where we would need to read mfg state to decide whether we need to publish the other protocol, but mfg state would also determine whether we used the protocol to disable the protection.<br /><br />Furthermore, there may be architectural (e.g. off-Soc) implementations of this that would still require a "lock" signal to disable their ability to receive the disable command. These solutions wouldn't have a concept of building with a "I want more security" PCD.<br /><br />Our recommendation would be to make sure that "lock" is called prior to leaving TCB, similar to SMM or other hardware locks (which the platform already has to coordinate).<br /><br />Two points to help manage this:<br />1) We would be willing to discuss adding a HSTI bit or DeviceState flag to indicate to an OS or attestation authority that the protections are disabled for the current boot.<br />2) We would recommend running the VarLockAudit test that we've provided with the release to make sure that not only are protections enabled, but the parameters of your policies are configured the way the platform wants them. It was very useful to us when trying to understand the overall system state we wanted.<br /><a style="font-size: medium;" href="https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra/UefiTestingPkg/AuditTests/UefiVarLockAudit">https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra/UefiTestingPkg/AuditTests/UefiVarLockAudit</a><br /><br />Looking forward to your thoughts.<br />Thanks!<br />- Bret