From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx.groups.io with SMTP id smtpd.web11.7158.1580907489490365378 for ; Wed, 05 Feb 2020 04:58:10 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: jiewen.yao@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2020 04:58:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,405,1574150400"; d="scan'208,217";a="249700073" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 05 Feb 2020 04:58:07 -0800 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 04:58:06 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 04:58:06 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.76]) with mapi id 14.03.0439.000; Wed, 5 Feb 2020 20:58:04 +0800 From: "Yao, Jiewen" To: "devel@edk2.groups.io" , "bret.barkelew@microsoft.com" , "rfc@edk2.groups.io" CC: "Yao, Jiewen" Subject: Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative Thread-Topic: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative Thread-Index: AQHV1ji67UKQxsv360e3bB8BQsJIDqgKtuRegAHdPKA= Date: Wed, 5 Feb 2020 12:58:03 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F91480C@shsmsx102.ccr.corp.intel.com> References: In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGJhMTBiOWYtNDM3Ny00Y2YzLTkzNjctZmEwMmIwNTJjNmIyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNW9xQUhWN0ZWTTNUblQ3XC9wc1NoaHk4QkpYM2o0SU5sM2tXUFJPVzFVTkR1ZTlwMUNqTUpTWEFRK2xHYWdxOGoifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-29T00:12:00.9680333Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: jiewen.yao@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_74D8A39837DF1E4DA445A8C0B3885C503F91480Cshsmsx102ccrcor_" --_000_74D8A39837DF1E4DA445A8C0B3885C503F91480Cshsmsx102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Bret Thanks for the work. The design doc is very good. Some feedback/questions below: 1. We have 2 variable related protocol - EDKII_VARIABLE_LOCK_PROTOCOL a= nd EDKII_VAR_CHECK_PROTOCOL. Do you want to deprecate both? Or only depreca= te EDKII_VARIABLE_LOCK_PROTOCOL? 2. The Function - DumpVariablePolicy() - makes me confused in the begin= ning. In my thought, "Dump" means to show some debug message. But here, you= want to return the policy. Can we change the name to GetVariablePolicy()? 3. The function - DisableVariablePolicy(). Does it disable current poli= cy engine? Does it disable any future policy engine? Does it block Register= VariablePolicy() call? 4. The function - LockVariablePolicy() - Can it lock the DisableVariabl= ePolicy() call? 5. The use case "In MFG Mode Variable Policy Engine is disabled, thus t= hese VPD variables can be created. These variables are locked with lock pol= icy type LockNow, so that these variables can't be tampered with in Custome= r Mode." This seems a perfect potential attack point. If the attacker wants to modi= fy a read-only variable. He or she may trigger the MFG mode, then no variab= le is locked. Then the attacker can update the RO variable then reset the s= ystem to normal mode. Is that threat considered? Thank you Yao Jiewen From: devel@edk2.groups.io On Behalf Of Bret Barkel= ew via Groups.Io Sent: Tuesday, February 4, 2020 4:08 PM To: devel@edk2.groups.io; rfc@edk2.groups.io Subject: Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and = Implementation for VariableLock Alternative Expanding the audience beyond the RFC list.... If no one has additional input, I'll try to start formatting these as patc= hes 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 fo= r 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 ov= er the summer and it is not our defacto variable solution. It plugs in easi= ly to the existing variable infrastructure, but does want to control some o= f 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 imple= mentation 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 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 in= terface. * The Extras piece contains recommended code for a full-feature implem= entation including a replacement for the VarLock protocol that enables exis= ting code to continue functioning as-is. It also contains unit and integrat= ion tests. And as a bonus, it has a Rust implementation of the core busines= s 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_extr= a A convenient way to see all the changes in one place is to look at a compa= rison: 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_c= ore...corthon:personal/brbarkel/var_policy_rfc_extra There's additional documentation in the PPT and DOC files in the core bran= ch: https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core= /RFC%20VariablePolicy%20Proposal%20Presentation.pptx https://github.com/cor= thon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%2= 0Whitepaper.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 lookin= g for initial feedback on any broad changes that might be needed to get thi= s into shape for more detailed code review on the devel list. Thanks! - Bret --_000_74D8A39837DF1E4DA445A8C0B3885C503F91480Cshsmsx102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI Bret

Thanks for the work. The design doc is very good.

 

Some feedback/questions below:

 

  1. We have 2 variable related protocol – EDKII_V= ARIABLE_LOCK_PROTOCOL and EDKII_V= AR_CHECK_PROTOCOL. Do you want to deprecate both? Or only deprecate EDKII_V= ARIABLE_LOCK_PROTOCOL?
  2. The Function – DumpVar= iablePolicy() – makes me confused in the beginning. In my thou= ght, “Dump” means to show some debug message. But here, you wan= t to return the policy. Can we change the name to GetVariablePolicy()?=
  3. The function - Disable= VariablePolicy(). Does it disable current policy engine? Does it dis= able any future policy engine? Does it block RegisterVariablePolicy() call?=
  4. The function – LockVar= iablePolicy() – Can it lock the DisableVariablePolicy() call?
  5. The use case “In MFG Mode Variable Policy Engi= ne is disabled, thus these VPD variables can be created. These variables ar= e locked with lock policy type LockNow, so that these variables can’t be tampered with in Customer Mode.”

    6. This seems a perfect potential attack point.= If the attacker wants to modify a read-only variable. He or she may trigge= r the MFG mode, then no variable is locked. Then the attacker can update th= e RO variable then reset the system to normal mode. Is that threat considered?

     

    Thank you

    Yao Jiewen

     

     

    From: de= vel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret Barkelew via Groups.Io
    Sent: Tuesday, February 4, 2020 4:08 PM
    To: devel@edk2.groups.io; rfc@edk2.groups.io
    Subject: Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Librarie= s, and Implementation for VariableLock Alternative

     

    Expanding the audience beyond the RFC list….<= o:p>

    If no one has additional input, I’ll try to s= tart 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 R= 20;VarLock-like” interface to constrain and govern platform variables= .

    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’s no different t= han the current VarLock implementation which has implementation code direct= ly tied to some of the common variable code.

     

    I’ve structured this RFC in two pieces:<= /o:p>

    • 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’s additional documentation in the PPT a= nd 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’d need to download those to view.)<= /o:p>

     

    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’m just looking for initial feedback on any broad changes th= at might be needed to get this into shape for more detailed code review on the devel list.

     

    Thanks!

     

    - Bret

     

     

--_000_74D8A39837DF1E4DA445A8C0B3885C503F91480Cshsmsx102ccrcor_--