Sorry, Jiewen. I missed this email when it came in...
1. We have 2 variable related protocol - EDKII_VARIABLE_LOCK_PROTOCOL and EDKII_VAR_CHECK_PROTOCOL. Do you want to deprecate both? Or only deprecate EDKII_VARIABLE_LOCK_PROTOCOL?I think we would recommend deprecating both. Is there much consumption of the VarCheck protocol? A platform could always opt to include both (or all 3!), but they wouldn't be able to immediately tell which engine rejected the SetVariable.
2. The Function - DumpVariablePolicy() - makes me confused in the beginning. In my thought, "Dump" means to show some debug message. But here, you want to return the policy. Can we change the name to GetVariablePolicy()?I see your point about possible confusion. I think we would try to clarify this in the function documentation. Due to the code-first approach we've taken on this, we already have partners who have implemented the policy with DumpVariablePolicy as the name and it doesn't seem like a huge problem.
3. The function - DisableVariablePolicy(). Does it disable current policy engine? Does it disable any future policy engine? Does it block RegisterVariablePolicy() call?Disable turns off the enforcement. You should still be able to register new policies for auditing purposes (they will still be returned by DumpVariablePolicy), but no SetVariables will be rejected.
4. The function - LockVariablePolicy() - Can it lock the DisableVariablePolicy() call?Correct. Once the interface is locked, it cannot be disabled. Locking should be performed at EndOfDxe or ReadyToBoot or wherever the platform TCB is.
5. The use case "In MFG Mode Variable Policy Engine is disabled, thus these VPD variables can be created. These variables are locked with lock policy type LockNow, so that these variables can't be tampered with in Customer Mode."Correct. The MfgMode is just a suggestion and is entirely up to the platform. Our MfgMode (which has not been open-sourced yet, but we're working on it) will call DisableVariablePolicy because our threat model indicates that compromising MfgMode is a total compromise (there are many other attack vectors once MfgMode is compromised). As such, we protect it extensively. But there is nothing in the core or extra code that would automatically disable the policy engine for any platform that didn't want that. It is up to the platform, however, to make sure they lock the policy engine (similar to locking SMM).