From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mx.groups.io with SMTP id smtpd.web10.8286.1583306756704025527 for ; Tue, 03 Mar 2020 23:25:56 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.120, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2020 23:25:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,513,1574150400"; d="scan'208";a="234025728" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga008.fm.intel.com with ESMTP; 03 Mar 2020 23:25:56 -0800 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 3 Mar 2020 23:25:56 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 3 Mar 2020 23:25:55 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.206]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.201]) with mapi id 14.03.0439.000; Wed, 4 Mar 2020 15:25:53 +0800 From: "Ni, Ray" To: "devel@edk2.groups.io" , "sunnywang@hpe.com" , Sean Brogan , "Kinney, Michael D" CC: "Wei, Kent (HPS SW)" , "Spottswood, Jason" Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020 Thread-Topic: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020 Thread-Index: AdXokAYaEXQ6OuujTiOhY+y7u3F98gJRh5FQAADQVeAAByWVQA== Date: Wed, 4 Mar 2020 07:25:52 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C47A6B3@SHSMSX104.ccr.corp.intel.com> References: <15F5603A467A59A4.15709@groups.io> <734D49CCEBEEF84792F5B80ED585239D5C479DB9@SHSMSX104.ccr.corp.intel.com> In-Reply-To: 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 Sunny, Let's discuss in this week's meeting to see whether the below enhancement = proposal can be aligned first. Thanks, Ray > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Wang, Sun= ny (HPS SW) > Sent: Wednesday, March 4, 2020 12:12 PM > To: devel@edk2.groups.io; Ni, Ray ; Sean Brogan ; Kinney, Michael D > > Cc: Wang, Sunny (HPS SW) ; Wei, Kent (HPS SW) ; Spottswood, Jason > > Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - F= eb 21, 2020 >=20 > Sorry for not making any progress since last meeting. > Sure! I will work on enhancing the variable policy to support partial pr= otection and recovery. However, the update will be > late because I need to first deal with other urgent stuff. > By the way, thanks for giving a lot of valuable comments at our offline = discussion, Ray. :) >=20 > Regards, > Sunny Wang >=20 > -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni= , Ray > Sent: Wednesday, March 4, 2020 11:46 AM > To: Sean Brogan ; Kinney, Michael D ; Wang, Sunny (HPS SW) > > Cc: Ni, Ray ; devel@edk2.groups.io > Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - F= eb 21, 2020 >=20 > Variable policy works well on protecting a whole variable. > But the BootOrder in Sunny's case may require a partial protection, whic= h 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, @Sunn= y can you please check whether it can meet your > requirement? >=20 > The enhancement I think of is: Introduce two fields to the policy struct= ure Offset and Length. > Offset (-1) indicates a whole variable protection. > Offset (>=3D 0) indicates a partial variable protection and the protecti= on range starts from Offset with Length bytes. >=20 > This enhancement is also useful when some policy fields inside a big pol= icy 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. >=20 >=20 > Thanks, > Ray >=20 > > -----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 - > > Feb 21, 2020 > > > > OPEN: > > Today's meeting is using Zoom because of the long latency using Blue= Jeans. > > The URL to join meeting is changed. Make sure to check https://edk2.= groups.io/g/devel/calendar for details. > > We will try Zoom for next meeting as well. If everything is good, we= will continue to use Zoom. > > > > 1. Platform Libraries for Supporting UEFI Variable Resiliency (HPE) > > Presenter: Sunny Wang > > Slides: > > INVALID URI REMOVED > > devel_files_Designs_2020_0221_Platform-2520Libraries-2520for-2520Suppo > > rting-2520UEFI-2520Variable-25&d=3DDwIFAg&c=3DC5b8zRQO1miGmBeVZ2LFWg&r= = =3DZ9c > > LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=3DU5okqrn3H585vxU4GwALnIBwi= 0s > > 0dQ0hYIDuFj2z-4Y&s=3DoG0quXKBZu3XD7Drm04CsF445C8kfOGOJGzeqACJxAA&e=3D > > 20Resiliency.pdf > > > > Problem: Support UEFI variable resiliency to compliant to security > > related guidelines and requirements. #page 2 > > > > 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 > > > > @Mike: Where is the reference data stored? > > @Sunny: In BMC. > > > > > > @Mike: Would like to see a small enhancement in variable policy protoc= ol proposed by Microsoft to meet your case. > > @Sunny: I checked the variable policy proposal by Microsoft. Using tha= t might be complicated. > > @Sean: We (Microsoft) have looked this. Variable hook in DXE phase not > > in SMM is a security hole. Don't like the way of managing BootOrder by > > allowing OS to change BootOrder and reverting. Boot#### may contain cr= itical data for OS and reverting that may cause > troubles. > > @Sunny: I cannot think of solutions for OS runtime change. > > > > > > @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 propo= sal 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. > > > > > > @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 ent= ity. > > @Ray: Is the protection based on not just the variable GUID/name, but = also who requests the change? > > @Sunny: Yes. Following sides (#page 10+) will talk about protection fr= om non-trusted entity. > > @Ray: Let's move to email discussion first. Identify the scope of the = problem first. > > > > Thanks, > > Ray > > > > >=20 >=20 >=20 >=20 >=20 >=20