From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) by mx.groups.io with SMTP id smtpd.web09.8237.1583308362160900962 for ; Tue, 03 Mar 2020 23:52:42 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.143.35, mailfrom: prvs=0332a85363=sunnywang@hpe.com) Received: from pps.filterd (m0134425.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0247o6nI027123 for ; Wed, 4 Mar 2020 07:52:41 GMT Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) by mx0b-002e3701.pphosted.com with ESMTP id 2yj7s6g9w5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 04 Mar 2020 07:52:41 +0000 Received: from G1W8106.americas.hpqcorp.net (g1w8106.austin.hp.com [16.193.72.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5008.houston.hpe.com (Postfix) with ESMTPS id A3BEE64 for ; Wed, 4 Mar 2020 07:52:40 +0000 (UTC) Received: from G9W8670.americas.hpqcorp.net (16.220.49.29) by G1W8106.americas.hpqcorp.net (16.193.72.61) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 4 Mar 2020 07:52:40 +0000 Received: from G4W10205.americas.hpqcorp.net (2002:10cf:520f::10cf:520f) by G9W8670.americas.hpqcorp.net (2002:10dc:311d::10dc:311d) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 4 Mar 2020 07:52:40 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (15.241.52.10) by G4W10205.americas.hpqcorp.net (16.207.82.15) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 4 Mar 2020 07:52:39 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iT/+GVwG2sw7z6BGm4xvQ+d7QmBarPPKno15IIKhj38zTpO3lc0vvZZqwRKctENmYwA/Cy04Uec8p+EPm/FQfrsShPj3HLyXaWuAfzP00+yOqGrPTEwmmX/8R1DoWd3qYuZ/41ktzm0P4DJxVPcaDfY+prSMLCbA/H1L6NbkUvcXpKFBB97hABAhvE9Oub4FuTMLCLffaqBWAblAzmQc2mNI3vyEOwlr5I0QYIDkeLZdrgCFH1xxPfFPu2LjZJ5iXbncCo6JH+ko5Z2Kz5H2w9lD+iWhIf5yIrWHfrPpSHh+Sd28HzRkMFI5WzS9LP+MiFeS/GcKcRWnH0K1RfW74w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K2DmfIj/NGRf9mcHi/4iBBN56QmObKs9QBn27g7wjlI=; b=BXVxjIgFRXQ/69hqPJ0IV8ZSWmgG8cshxmcRIiYswysTcOvjwwdISG2YNm7B7rxshymlyskjeis6ahVgC7aFbLxsin6PcyT5NRCUqgCZAx9sJ3weS5gdlhUh3Ae3MqGGCW/o25Xm5IUfE3qC0GrmCmluDrgysSR+9KyyubCSxc5s56GT2LI2Acoz0TQJNAxgrKwkcSKVR6djkqufD3hJ2dwOH1M9ZLLmXrEaydDHDx6Ko51+xuXlNOdBhTDbDOFVTWI9HcyuOV3rqKMoTD6AvQlSFxQRBB/BDrhOQvyRftoU/Psnl8xSSk9bPRZ4uh6lbIz780kEkoPoUIvKPTvJCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from DF4PR8401MB0585.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7609::21) by DF4PR8401MB0393.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7605::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Wed, 4 Mar 2020 07:52:31 +0000 Received: from DF4PR8401MB0585.NAMPRD84.PROD.OUTLOOK.COM ([fe80::55d9:319c:de69:105d]) by DF4PR8401MB0585.NAMPRD84.PROD.OUTLOOK.COM ([fe80::55d9:319c:de69:105d%2]) with mapi id 15.20.2772.018; Wed, 4 Mar 2020 07:52:31 +0000 From: "Wang, Sunny (HPS SW)" To: "devel@edk2.groups.io" , "ray.ni@intel.com" , Sean Brogan , "Kinney, Michael D" CC: "Wei, Kent (HPS SW)" , "Spottswood, Jason" , "Wang, Sunny (HPS SW)" 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+y7u3F98gJRh5FQAADQVeAAByWVQAAA5Xow Date: Wed, 4 Mar 2020 07:52:31 +0000 Message-ID: References: <15F5603A467A59A4.15709@groups.io> <734D49CCEBEEF84792F5B80ED585239D5C479DB9@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C47A6B3@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C47A6B3@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.242.247.133] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8758f5c1-144c-4e8e-5c0f-08d7c010fe6b x-ms-traffictypediagnostic: DF4PR8401MB0393: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2887; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(396003)(136003)(346002)(366004)(39860400002)(376002)(189003)(199004)(53546011)(66476007)(6506007)(2906002)(66446008)(8936002)(966005)(66946007)(64756008)(86362001)(66556008)(76116006)(33656002)(7696005)(8676002)(110136005)(26005)(52536014)(5660300002)(81166006)(55016002)(4326008)(81156014)(9686003)(478600001)(186003)(54906003)(71200400001)(316002)(45080400002);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR8401MB0393;H:DF4PR8401MB0585.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KX/86RvdWqREHNXWA3qSuqqKkcwBOMHMmcIGKwRjhK3KFsLt6gw5hX6A9da8lkR2i48O1Nn2uptTBez1qTOOpwhxcYqcMrhAMK/I1MVHrkjf2Fu04okXN77fFCrO0HbEqU8xqCIhEGZQBBgtPeCf1DGI/ow7m3Apz3yRZEuUNqh49KDZ17077CHe8RL2Ndx6I/zbb55K0TaiB9+aa/6myTI0Zilc8z/ADx+OMYxngB4uHu6gZUOVFcYdJcloYGoLSMxPOxSdR2vxILyedAjFHsQmy9eVs3zgtRYIfuvuIlq4mKdj0YNCfXOJOLGCc1ZstzLfZUZ1fnHDhREIKFb6UIuboo5/oJMOB7tVewMZavAoIrFSjSXR43DVdG09gZIbvIKHpPTFRYd27tD8N2jA4BMWQMsXEjXfgneUL4KfcV47bkLHGeerLmb0abDEv7+tx421Za8ZiMZNxrAoPbmHLIS19oikUm5CnT2UDeZ90RC8N2/mCkG+duA5S536of7wBeFHq3onW+ku5Ag2DDbt8Q== x-ms-exchange-antispam-messagedata: jDS8j/Xi8srqGV/2HlLRR44s1xjKjzk+ra9kpT8YM9eS7q8FXCPP5sSbdq0khvsmHYmgCwwkxz0Ia+ows99OmBfuuxAqHwI0j8p5c6/yHEDDW6Qqa8LcpWaWzoPJYOP95R+Ke0/PFBwCsNaa7Ktu+Q== X-MS-Exchange-CrossTenant-Network-Message-Id: 8758f5c1-144c-4e8e-5c0f-08d7c010fe6b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2020 07:52:31.5733 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7kaGsosRzFmW9dunBdjJ5pB3kuAJSL2A6h/UajGvzsjzaK9XNQqI/8oDzwKd9u9yWV46qV3zw7rvJj7M5fszFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0393 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 4 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572 definitions=2020-03-04_01:2020-03-03,2020-03-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 adultscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 bulkscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003040060 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure! Regards, Sunny Wang -----Original Message----- From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni, = Ray Sent: Wednesday, March 4, 2020 3:26 PM To: devel@edk2.groups.io; Wang, Sunny (HPS SW) ; Sean B= rogan ; Kinney, Michael D Cc: Wei, Kent (HPS SW) ; Spottswood, Jason Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb= 21, 2020 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,=20 > Sunny (HPS SW) > Sent: Wednesday, March 4, 2020 12:12 PM > To: devel@edk2.groups.io; Ni, Ray ; Sean Brogan=20 > ; Kinney, Michael D=20 > > Cc: Wang, Sunny (HPS SW) ; Wei, Kent (HPS SW)=20 > ; Spottswood, Jason > Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes -= =20 > Feb 21, 2020 >=20 > Sorry for not making any progress since last meeting. > Sure! I will work on enhancing the variable policy to support partial=20 > protection 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=20 > offline discussion, Ray. :) >=20 > Regards, > Sunny Wang >=20 > -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of=20 > Ni, Ray > Sent: Wednesday, March 4, 2020 11:46 AM > To: Sean Brogan ; Kinney, Michael D=20 > ; Wang, Sunny (HPS SW) > Cc: Ni, Ray ; devel@edk2.groups.io > Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes -= =20 > Feb 21, 2020 >=20 > Variable policy works well on protecting a whole variable. > But the BootOrder in Sunny's case may require a partial protection,=20 > 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,=20 > @Sunny 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=20 > 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= =20 > > Ni, Ray > > Sent: Friday, February 21, 2020 5:17 PM > > To: announce@edk2.groups.io > > Subject: [edk2-announce] TianoCore Community Design Meeting Minutes=20 > > - 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-2520Sup > > po=20 > > rting-2520UEFI-2520Variable-25&d=3DDwIFAg&c=3DC5b8zRQO1miGmBeVZ2LFWg&r= = =3DZ > > 9c=20 > > LgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=3DU5okqrn3H585vxU4GwALnIBwi > > 0s 0dQ0hYIDuFj2z-4Y&s=3DoG0quXKBZu3XD7Drm04CsF445C8kfOGOJGzeqACJxAA&e= =3D > > 20Resiliency.pdf > > > > Problem: Support UEFI variable resiliency to compliant to security=20 > > 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:=20 > > #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=20 > > not in SMM is a security hole. Don't like the way of managing=20 > > BootOrder by allowing OS to change BootOrder and reverting. Boot####= =20 > > may contain critical 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=20 > > 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=20 > > 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