From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx.groups.io with SMTP id smtpd.web12.6654.1583293609941698778 for ; Tue, 03 Mar 2020 19:46:50 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2020 19:46:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,511,1574150400"; d="scan'208";a="319690432" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 03 Mar 2020 19:46:47 -0800 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 3 Mar 2020 19:46:06 -0800 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 3 Mar 2020 19:46:06 -0800 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 3 Mar 2020 19:46:05 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.206]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.145]) with mapi id 14.03.0439.000; Wed, 4 Mar 2020 11:46:04 +0800 From: "Ni, Ray" To: Sean Brogan , "Kinney, Michael D" , "Wang, Sunny (HPS SW)" CC: "Ni, Ray" , "devel@edk2.groups.io" Subject: Re: TianoCore Community Design Meeting Minutes - Feb 21, 2020 Thread-Topic: TianoCore Community Design Meeting Minutes - Feb 21, 2020 Thread-Index: AdXokAYaEXQ6OuujTiOhY+y7u3F98gJRh5FQ Date: Wed, 4 Mar 2020 03:46:03 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C479DB9@SHSMSX104.ccr.corp.intel.com> References: <15F5603A467A59A4.15709@groups.io> In-Reply-To: <15F5603A467A59A4.15709@groups.io> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Variable policy works well on protecting a whole variable. But the BootOrder in Sunny's case may require a partial protection, which = means portion of the variable buffer needs to be read-only. Today's variable policy proposal doesn't take this into consideration. If we could enhance variable policy to support partial protection, @Sunny = can you please check whether it can meet your requirement? The enhancement I think of is: Introduce two fields to the policy structur= e Offset and Length. Offset (-1) indicates a whole variable protection. Offset (>=3D 0) indicates a partial variable protection and the protection= range starts from Offset with Length bytes. This enhancement is also useful when some policy fields inside a big polic= y structure needs to be read-only. Protecting multiple discontinuous ranges of a variable can be achieved by= adding multiple policy entries with different Offset/Length. Thanks, Ray > -----Original Message----- > From: announce@edk2.groups.io On Behalf Of Ni,= Ray > Sent: Friday, February 21, 2020 5:17 PM > To: announce@edk2.groups.io > Subject: [edk2-announce] TianoCore Community Design Meeting Minutes - Fe= b 21, 2020 >=20 > OPEN: > Today's meeting is using Zoom because of the long latency using BlueJe= ans. > The URL to join meeting is changed. Make sure to check https://edk2.gr= oups.io/g/devel/calendar for details. > We will try Zoom for next meeting as well. If everything is good, we w= ill continue to use Zoom. >=20 > 1. Platform Libraries for Supporting UEFI Variable Resiliency (HPE) > Presenter: Sunny Wang > Slides: > https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform%20Librar= ies%20for%20Supporting%20UEFI%20Variable% > 20Resiliency.pdf >=20 > Problem: Support UEFI variable resiliency to compliant to security relat= ed guidelines and requirements. #page 2 >=20 > Locking BootOrder causes issues in OSes which is not acceptable. > EDKII is lack of interfaces for adding platform variable protection. > Today's presentation is to propose a solution. > Basic rule of how variable resiliency manages BootOrder changes: #5-#6 > - Put down untrusted changes > - Keep trusted changes >=20 > @Mike: Where is the reference data stored? > @Sunny: In BMC. >=20 > > @Mike: Would like to see a small enhancement in variable policy protocol= proposed by Microsoft to meet your case. > @Sunny: I checked the variable policy proposal by Microsoft. Using that = might be complicated. > @Sean: We (Microsoft) have looked this. Variable hook in DXE phase not i= n SMM is a security hole. Don't like the way of > managing BootOrder by allowing OS to change BootOrder and reverting. Boo= t#### may contain critical data for OS and > reverting that may cause troubles. > @Sunny: I cannot think of solutions for OS runtime change. >=20 > > @Mike: I would break the big problem to 3 smaller ones: > 1. variable data corruption > It requires a way to detect corruption and recovery. > 2. critical platform variables > It usually requires a lock mechanism and variable policy proposa= l is more general for this protection. > 3. UEFI variables with multiple producers > How to protect them could be a topic for USWG. > @Sean: The scope of the problem discussed in this presentation is huge. = Can a platform module run at a different point of > time to manage the variable storage instead of using hook way? > @Sunny: BootOrder is just one of the variables that need protection. >=20 > > @Mike: Using a separate platform module might be better because it will = also check the variables not changed by > firmware. > @Sean: PEI modules may access the wrong data modified by untrusted entit= y. > @Ray: Is the protection based on not just the variable GUID/name, but al= so who requests the change? > @Sunny: Yes. Following sides (#page 10+) will talk about protection from= non-trusted entity. > @Ray: Let's move to email discussion first. Identify the scope of the pr= oblem first. >=20 > Thanks, > Ray >=20 >=20