From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [edk2-rfc] [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative To: Yao, Jiewen ,devel@edk2.groups.io From: "Bret Barkelew" X-Originating-Location: Seattle, Washington, US (174.21.64.62) X-Originating-Platform: Windows Chrome 81 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 06 Feb 2020 22:00:05 -0800 References: <74D8A39837DF1E4DA445A8C0B3885C503F918A9C@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503F918A9C@shsmsx102.ccr.corp.intel.com> Message-ID: <15873.1581055205006059831@groups.io> Content-Type: multipart/alternative; boundary="k32pslPQMBKfflUOLfI6" --k32pslPQMBKfflUOLfI6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with you that this function is extremely sensitive and important, a= nd I kinda like your idea of splitting the protocol into a "policy" and "po= licy 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 othe= r 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 r= eceive the disable command. These solutions wouldn't have a concept of buil= ding with a "I want more security" PCD. Our recommendation would be to make sure that "lock" is called prior to le= aving TCB, similar to SMM or other hardware locks (which the platform alrea= dy 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 disabl= ed for the current boot. 2) We would recommend running the VarLockAudit test that we've provided wi= th 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 stat= e we wanted. https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extr= a/UefiTestingPkg/AuditTests/UefiVarLockAudit Looking forward to your thoughts. Thanks! - Bret --k32pslPQMBKfflUOLfI6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with you that this function is extremely sensitive and important, a= nd I kinda like your idea of splitting the protocol into a "policy" and "po= licy 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 othe= r protocol, but mfg state would also determine whether we used the protocol= to disable the protection.

Furthermore, there may be architectu= ral (e.g. off-Soc) implementations of this that would still require a "lock= " signal to disable their ability to receive the disable command. These sol= utions wouldn't have a concept of building with a "I want more security" PC= D.

Our recommendation would be to make sure that "lock" is calle= d prior to leaving TCB, similar to SMM or other hardware locks (which the p= latform already has to coordinate).

Two points to help manage th= is:
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 ar= e disabled for the current boot.
2) We would recommend running the Var= LockAudit test that we've provided with the release to make sure that not o= nly are protections enabled, but the parameters of your policies are config= ured the way the platform wants them. It was very useful to us when trying = to understand the overall system state we wanted.
https://gi= thub.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra/UefiTesti= ngPkg/AuditTests/UefiVarLockAudit

Looking forward to your th= oughts.
Thanks!
- Bret --k32pslPQMBKfflUOLfI6--