TianoCore Community Design Meeting Minutes

Ni, Ray

Minutes I captured in the meeting. Please feel free to reply and add the missing parts I failed to capture.
Please reply for any questions or comments.

Bret - could you please reply to this mail with the white paper URL after it's published?

Bret Barkelew (MSFT) - VariablePolicy Interface as a replacement to Variable Lock Protocol
Slides: https://edk2.groups.io/g/devel/files/Designs/2019/0516/2019-05-09%20VariablePolicy%20Protocol%20v1.0.pdf
Code: https://github.com/microsoft/mu_basecore/commit/b8104538c89f758f8fa9464c67419595fe73b2d7

Variable Policy Elements
- Identify certain variables: Namespace, Name
- Policies: Min/Max Size, AttributesMustHave/AttributesCantHave, LockPolicyType

- No Lock
- Lock Now
- Lock On Creation: similar to write-once concept
- Lock On VAR State: lock upon a state change of another "delegate variable"
(For now it only supports lock upon a certain value of another delegate variable)
Delegate variable: Namespace, Name, Value

Doesn't provide locking on event (EndOfDxe) capability.

Detailed explanation of variable policy is in a white paper Bret will send out later.

Mike: Any that helps to debug if policies are complex?
Bret: Unit test code is ready.

Ray: Delegate variable can be changed which impacts the lock.
Bret: Delegate variables can be in the same namespace, guarded by Lock On Creation.
Target variable is lock on state of delegate variable.

Mike: Spec allows variable such as '#'. How to distinguish between number wide char '#' and a real '#'?
Bret: In current implementation, '#' matches both '#' and numbers.

Policies that are more specific override generic ones.
Current definition of specific: number of '#'.
May not ideal, open for comments after white paper is published.

Felix: Besides VarCheck lib mentioned in slides, there is VarCheck protocol. Can that meet your needs?
Bret: VarCheck protocol is not using SMM infra so no protection of policy itself.
Bret: Open to option expanding the existing interfaces (VarCheck).
Bret: No common policy logic for PK and etc. AUTH variables using VarCheck protocol.

Felix: Existing VarLock tying to EndOfDxe follows the UEFI firmware security model.
Felix: When there are different policies registered from different drivers, maybe it's more
proper to more restricted policies take higher priority, instead of more specific policies
take higher priority.

VariablePolicy protocol is produced only in boot service.
The policy engine is still running in runtime.

Propose to replace VarLock protocol with the new VariablePolicy protocol
VarCheck is kept and in fact the VariablePolicy is implemented through VarCheck currently.