Re: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

["Wang, Sunny (HPS SW)" <sunnywang@hpe.com>]

Hi Bret, 

Your proposal looks good to me, and most of my questions/concerns were already answered/solved by the GOOD discussion between you and Jiewen.

For now, I just have one remaining question. Can we also make DumpVariablePolicy as a platform choice? 
DumpVariablePolicy would also expose the information about how to pass the check to the attacker. If my understanding is correct, the attacker can even use the information to unlock the variable locked by LOCK_ON_VAR_STATE type policy. Therefore, If the DumpVariablePolicy is just to allow platform tests to audit the entire policy list, can we add a PCD or a build flag check to disable it in release build? Of course, I also agree with Jiewen's point about making DisableVarPolicy as a platform choice.

By the way, I had the other question that I already got the answer from the code and your document. Since it hasn't been discussed, I think it would be good to share the answer with others. The question is how VariablePolicy deals with the multiple RegisterVariablePolicy calls with the same variable name and GUID. The answer is that the first registered policy will be the winner. The later calls (from attackers) with the same name and GUID will just get EFI_ALREADY_STARTED and fail to register the compromised policy. Therefore, RegisterVariablePolicy looks good to me as well. 


Regards,
Sunny Wang

-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Bret Barkelew via Groups.Io
Sent: Wednesday, January 29, 2020 9:36 AM
To: rfc@edk2.groups.io
Subject: [edk2-rfc] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

All,

VariablePolicy is our proposal for an expanded "VarLock-like" interface to constrain and govern platform variables.
I brought this up back in May to get initial comments on the interface and implications of the interface and the approach. We implemented it in Mu over the summer and it is not our defacto variable solution. It plugs in easily to the existing variable infrastructure, but does want to control some of the things that are currently managed by VarLock.

There are also some tweaks that would be needed if this were desired to be 100% optional code, but that's no different than the current VarLock implementation which has implementation code directly tied to some of the common variable code.

I've structured this RFC in two pieces:

  *   The Core piece represents the minimum changes needed to implement Variable Policy and integrate it into Variable Services. It contains core driver code, central libraries and headers, and DXE driver for the protocol interface.
  *   The Extras piece contains recommended code for a full-feature implementation including a replacement for the VarLock protocol that enables existing code to continue functioning as-is. It also contains unit and integration tests. And as a bonus, it has a Rust implementation of the core business logic for Variable Policy.

The code can be found in the following two branches:
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra

A convenient way to see all the changes in one place is to look at a comparison:
https://github.com/corthon/edk2/compare/master...corthon:personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/compare/personal/brbarkel/var_policy_rfc_core...corthon:personal/brbarkel/var_policy_rfc_extra

There's additional documentation in the PPT and DOC files in the core branch:
https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Proposal%20Presentation.pptx https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Whitepaper.docx
(You'd need to download those to view.)

My ultimate intention for this is to submit it as a series of patches for acceptance into EDK2 as a replacement for VarLock. For now, I'm just looking for initial feedback on any broad changes that might be needed to get this into shape for more detailed code review on the devel list.

Thanks!

- Bret