From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out04.hibox.biz (out04.hibox.biz [210.71.195.42]) by mx.groups.io with SMTP id smtpd.web09.2040.1580858966937046374 for ; Tue, 04 Feb 2020 15:29:28 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: insyde.com, ip: 210.71.195.42, mailfrom: kevin.davis@insyde.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DBAAAD/jle/ws0GKxlGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gSWBcIExhBRhkCQlgQCCboFPggCHRIQsiAs?= =?us-ascii?q?JAQEBAQEBAQEBCCcIAQGBTIIvRQIggjs4EwIQAQEFAQEBAQEFBIVYTAyFZgE?= =?us-ascii?q?BAgIBIysrBRYNBAQBAQENFgcCMx4IBxIbAgSDBQGCWy+rRRo1dYEyGgKEGQG?= =?us-ascii?q?BFINbgT6BOIFlhB2Hez+BOAwUgh4uPoJDIQIBAYFjCIMIMoIsBJc5RogujzY?= =?us-ascii?q?Hgj6HSY56G4NAi0sDi3qERIodiGePBYNWgWmBek0jUCoBgkEJNRIYjmKDO4J?= =?us-ascii?q?kiA5VAo5LAQE?= X-IronPort-AV: E=Sophos;i="5.70,403,1574092800"; d="scan'208,217";a="20703734" Received: from unknown (HELO hb3-BKT201.hibox.biz) ([172.24.52.11]) by out04.hibox.biz with ESMTP; 05 Feb 2020 07:28:52 +0800 IronPort-SDR: LSAYWAxdZGMEKpi7ozBGJ0OLVLz5iBIQIFNJJHaP6lD1Yvq5a3+CfuGeap88rvvm/LUak46Y5O pZ12Dl4GyD/A== Received: from unknown (HELO hb3-BKT103.hibox.biz) ([172.24.51.13]) by hb3-BKT201.hibox.biz with ESMTP; 05 Feb 2020 07:28:53 +0800 IronPort-SDR: buW4pTz4rDLjoqYjLd5mfQ1IPfeyGKmBmZz9iaOW+zAcXSElYUJ7tSdnAliWlC1iZUbHcYr0JY lGIpZwx0go8A== Received: from unknown (HELO hb3-IN02.hibox.biz) ([172.24.12.12]) by hb3-BKT103.hibox.biz with ESMTP; 05 Feb 2020 07:28:52 +0800 X-Remote-IP: 107.92.63.216 X-Remote-Host: mobile-107-92-63-216.mycingular.net X-SBRS: -10.0 X-MID: 33834342 X-Auth-ID: kevin.davis@insyde.com X-EnvelopeFrom: kevin.davis@insyde.com Received: from mobile-107-92-63-216.mycingular.net (HELO [192.168.50.14]) ([107.92.63.216]) by hb3-IN02.hibox.biz with ESMTP/TLS/AES256-SHA; 05 Feb 2020 07:28:51 +0800 Mime-Version: 1.0 (1.0) Subject: Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative From: "Kevin@Insyde" In-Reply-To: Date: Tue, 4 Feb 2020 17:28:37 -0600 Cc: "rfc@edk2.groups.io" Message-Id: <00D41E65-7B77-4326-A363-A65061B281BF@insyde.com> To: devel@edk2.groups.io, bret.barkelew@microsoft.com X-Mailer: iPhone Mail (17D50) Content-Type: multipart/alternative; boundary=Apple-Mail-7A3A985D-0FC5-402C-A24A-A1BC369798B5 Content-Transfer-Encoding: 7bit --Apple-Mail-7A3A985D-0FC5-402C-A24A-A1BC369798B5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bret, We like the new functionality. Our concern is our customers / we will need to modify all of the code that= are consumers of EDKII_VARIABLE_LOCK_PROTOCOL to use the new protocols. I= f you could review that issue we would be 100% happy. Of course, that=E2=80=99s not always appropriate and we understand. Kevin D Davis Insyde Software > On Feb 4, 2020, at 2:07 AM, Bret Barkelew via Groups.Io wrote: >=20 > =EF=BB=BF > Expanding the audience beyond the RFC list=E2=80=A6. > If no one has additional input, I=E2=80=99ll try to start formatting the= se as patches later this week. Thanks! > > - Bret > > From: Bret Barkelew > Sent: Tuesday, January 28, 2020 5:36 PM > To: rfc@edk2.groups.io > Subject: [RFC] VariablePolicy - Protocol, Libraries, and Implementation = for VariableLock Alternative > > All, > > VariablePolicy is our proposal for an expanded =E2=80=9CVarLock-like=E2= =80=9D interface to constrain and govern platform variables. > I brought this up back in May to get initial comments on the interface a= nd 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 ea= sily 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=E2=80=99s no different than the current Var= Lock implementation which has implementation code directly tied to some of = the common variable code. > > I=E2=80=99ve structured this RFC in two pieces: > The Core piece represents the minimum changes needed to implement Variab= le Policy and integrate it into Variable Services. It contains core driver = code, central libraries and headers, and DXE driver for the protocol interf= ace. > The Extras piece contains recommended code for a full-feature implementa= tion 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 lo= gic for Variable Policy. > > The code can be found in the following two branches: > https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_co= re > https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_ex= tra > > A convenient way to see all the changes in one place is to look at a com= parison: > https://github.com/corthon/edk2/compare/master...corthon:personal/brbark= el/var_policy_rfc_core > https://github.com/corthon/edk2/compare/personal/brbarkel/var_policy_rfc= _core...corthon:personal/brbarkel/var_policy_rfc_extra > > There=E2=80=99s additional documentation in the PPT and DOC files in the= core branch: > https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_co= re/RFC%20VariablePolicy%20Proposal%20Presentation.pptx https://github.com/c= orthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy= %20Whitepaper.docx > (You=E2=80=99d need to download those to view.) > > My ultimate intention for this is to submit it as a series of patches fo= r acceptance into EDK2 as a replacement for VarLock. For now, I=E2=80=99m j= ust 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 > > >=20 --Apple-Mail-7A3A985D-0FC5-402C-A24A-A1BC369798B5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bret,

We like the n= ew functionality.

Our concern is our customers / w= e will need to modify all of the code that are consumers of EDKII_VARIABLE_= LOCK_PROTOCOL to use the new protocols.  If you could review that issu= e we would be 100% happy.

Of course, that=E2=80=99= s not always appropriate and we understand.

Ke= vin D Davis

Insyde Software

<= /td>

On Feb 4, 2020, at 2:07 AM, Bret Barkelew via Groups.Io <bret= .barkelew=3Dmicrosoft.com@groups.io> wrote:

=EF=BB=BF

Expanding the audience beyond the RFC list=E2=80=A6= .

If no one has additional input, I=E2=80=99ll try to= start formatting these as patches later this week. Thanks!

 

- Bret

 

From: Bret Barkelew
Sent: Tuesday, January 28, 2020 5:36 PM
To: rfc@edk2.groups.io Subject: [RFC] VariablePolicy - Protocol, Libraries, and Implementa= tion for VariableLock Alternative

 

All,

 

VariablePolicy is our proposal for an expanded =E2= =80=9CVarLock-like=E2=80=9D interface to constrain and govern platform var= iables.

I brought this up back in May to get initial commen= ts 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 sol= ution. 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=E2=80=99s no different= than the current VarLock implementation which has implementation code dire= ctly tied to some of the common variable code.

 

I=E2=80=99ve structured this RFC in two pieces:

  • The Core piece represents the minimum changes needed to implement Va= riable Policy and integrate it into Variable Services. It contains core dri= ver code, central libraries and headers, and DXE driver for the protocol interface.
  • The Extra= s piece contains recommended code for a full-feature implementation includi= ng a replacement for the VarLock protocol that enables existing code to con= tinue functioning as-is. It also contains unit and integration tests. And as a bonus, it has a Rus= t 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/pe= rsonal/brbarkel/var_policy_rfc_core

https://github.com/corthon/edk2/tree/p= ersonal/brbarkel/var_policy_rfc_extra

 

A convenient way to see all the changes in one plac= e 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=E2=80=99s additional documentation in the PPT= and DOC files in the core branch:

https://github.com/corthon/edk2/blob/personal/brbarkel/var_pol= icy_rfc_core/RFC%20VariablePolicy%20Proposal%20Presentation.pptx https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core= /RFC%20VariablePolicy%20Whitepaper.docx

(You=E2=80=99d 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. F= or now, I=E2=80=99m 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

 

 

--Apple-Mail-7A3A985D-0FC5-402C-A24A-A1BC369798B5--