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.

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.

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).

Two points to help manage this:
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.
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.
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra/UefiTestingPkg/AuditTests/UefiVarLockAudit

Looking forward to your thoughts.
Thanks!
- Bret

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53998): https://edk2.groups.io/g/devel/message/53998
Mute This Topic: https://groups.io/mt/71035502/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to