From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) by mx.groups.io with SMTP id smtpd.web09.6873.1583295097771227013 for ; Tue, 03 Mar 2020 20:11:37 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.147.86, mailfrom: prvs=0332a85363=sunnywang@hpe.com) Received: from pps.filterd (m0150242.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02448MNB031955 for ; Wed, 4 Mar 2020 04:11:37 GMT Received: from g2t2352.austin.hpe.com (g2t2352.austin.hpe.com [15.233.44.25]) by mx0a-002e3701.pphosted.com with ESMTP id 2yj3w78nea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 04 Mar 2020 04:11:37 +0000 Received: from G9W8455.americas.hpqcorp.net (g9w8455.houston.hp.com [16.216.161.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2352.austin.hpe.com (Postfix) with ESMTPS id 7564C62 for ; Wed, 4 Mar 2020 04:11:36 +0000 (UTC) Received: from G2W6309.americas.hpqcorp.net (2002:10c5:4033::10c5:4033) by G9W8455.americas.hpqcorp.net (2002:10d8:a15e::10d8:a15e) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 4 Mar 2020 04:11:36 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (15.241.52.11) by G2W6309.americas.hpqcorp.net (16.197.64.51) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 4 Mar 2020 04:11:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lBFonE0VnzY/RAWBoiytNlbsycqAQ6iBjOnonFZFs92eVVpRCWaxenXUKh9zI++Y0wtbFEdNq0mJTf/57WhjYntUjOas0Ab/a8iFnMRbe+ISgNA4nwB5PzErIXCsh490vHItFMmlQ1PCs0KJSZ0HTWaEVqAJMpJxhXgkIiGcKRuo/6Bp22cEW/j8PPSE/NauzqgHnaJioJSIo36T7QzBA4DYUZpXtQk93DZM0Qm7OITDKyyXrz4UbkLaUUxew1FUJ7OGw1Guq7AJTGKci1m6jW+QUTbuYpmnInNZ2ihKzCZLpTE2/ECHxqHfKF3Hdv17nAJCIr6xt2+6QZKHl2V1cQ== 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=UGGlD9g9mBdFQhzwrmKvloEJvJpw7n0sDFVU5Vuv9ec=; b=Bbasl5fayjgMmUMvn3FDvyv6TlgycO/tykWU0ghClUvw1V4qsXqG/azLxSOlRuUz84sS4q49XpMVeOGfTKZmk/gkGMeJXDghqegtXy1ooxNXgh6hj7m5sDGXYs7l0xJLcp3y/MOZT7UWRI8vAarT6pfw5TIGIZ1ASZcQxLkJWAMSqRjYjN8meVVT3pd1FLrhsjKlYV6/w9IyoC/hfohFiCcaCiiGOYtbV7Vi9vP2WMX8l8bzhawqq8Wd032Ih/Fxj9XcQNS+7As2Sfz8/Qeu74sHlIJXsp07Z7bCHBG1M+yUNezVyhjpQ9z18Dm1KWQ3+FIWx421X0uDknIQv8+ZoQ== 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 DF4PR8401MB1209.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7611::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Wed, 4 Mar 2020 04:11:33 +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 04:11:33 +0000 From: "Wang, Sunny (HPS SW)" To: "devel@edk2.groups.io" , "ray.ni@intel.com" , 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 - Feb 21, 2020 Thread-Topic: [edk2-devel] TianoCore Community Design Meeting Minutes - Feb 21, 2020 Thread-Index: AdXokAYaEXQ6OuujTiOhY+y7u3F98gJRh5FQAADQVeA= Date: Wed, 4 Mar 2020 04:11:32 +0000 Message-ID: References: <15F5603A467A59A4.15709@groups.io> <734D49CCEBEEF84792F5B80ED585239D5C479DB9@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C479DB9@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: fb82db1e-2c6d-4947-fb32-08d7bff21fc4 x-ms-traffictypediagnostic: DF4PR8401MB1209: 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)(376002)(396003)(39860400002)(366004)(346002)(136003)(189003)(199004)(186003)(66446008)(45080400002)(26005)(52536014)(966005)(4326008)(55016002)(9686003)(478600001)(6506007)(54906003)(66946007)(64756008)(2906002)(76116006)(316002)(86362001)(53546011)(71200400001)(8936002)(66476007)(110136005)(66556008)(8676002)(5660300002)(33656002)(81166006)(81156014)(7696005);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR8401MB1209;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: civHIYHEe6H+HKSMTaFgbkaW6iB79TEtgeMie5rNJnvk+KboAV0pTBo/7cjFOFUryltBS+EUIZNuP8mCJpBhtsWB8ydHCKMASa8ewKmG7eboRr/OqZHTzd0uku0Jpf5vjpupuH+bA91y/LpW2O/tieW3brns7lkQgGmekM7v3HS8ZpnBY9/dFUJLce/YQNabiCHDxKOPnfdrrql6qITr7NBUnOw6TntNSPH5F3KqZlmArSnv3Bw602XHO90BSHdvDqGvM7bIx7fmV5b8sKKRxXsEUSiGd+r+PJkRux0pK2YI8QFRzfrr4vmIv2d6tT7ffPpN1nPUCm9JXm7tJKL+TD5bRcOKUh5fwJ0jCzNqt4dJm7BaSDNGgU9zWK81hPgtpT1OSh7yPLZwJhnB6taPCxHBhJm5OZ5u1GIP1Si3JbJPFYBeQNI4H3jL8Oj7MUH5lDqzWPzoD2c5bSTX62lZs0OOSUF2Wf42Y5JSvSXr+7LmQhxTT6s2MAcBH7HdnByQvQjMcPd/2cDVKLB1DkVzpQ== x-ms-exchange-antispam-messagedata: Ei3rSFajNP9WLT64zYxNI2Co6TTOpeaOXtOWZ8A92zX0QBscN4RhkhXnq2VZKorkEIhI8vIsAbLniZ0FbjXoqWoXsdNwXrxnNSHPtEewyI3nH6nZgCuGCSgzA0uG5OA+jvodcgiwyO78LpeA9Nuqrg== X-MS-Exchange-CrossTenant-Network-Message-Id: fb82db1e-2c6d-4947-fb32-08d7bff21fc4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2020 04:11:33.0259 (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: q73fyoaJJ86Yt3Wt/TRsUxaqxYVlp0r3Lw1Y8yMmOkRSN2CM0oV1U/tkNwjuGWXbHN+m8P4Fpoaebf0H5HndsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB1209 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-03_08:2020-03-03,2020-03-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 priorityscore=1501 bulkscore=0 phishscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 lowpriorityscore=0 impostorscore=0 spamscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003040028 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for not making any progress since last meeting. Sure! I will work on enhancing the variable policy to support partial prot= ection and recovery. However, the update will be late because I need to fir= st deal with other urgent stuff. By the way, thanks for giving a lot of valuable comments at our offline di= scussion, Ray. :) 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 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 - Feb= 21, 2020 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=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 >=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: > 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=3DU5okqrn3H585vxU4GwALnIBwi0s > 0dQ0hYIDuFj2z-4Y&s=3DoG0quXKBZu3XD7Drm04CsF445C8kfOGOJGzeqACJxAA&e=3D > 20Resiliency.pdf >=20 > Problem: Support UEFI variable resiliency to compliant to security=20 > related 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= =20 > in SMM is a security hole. Don't like the way of managing BootOrder by= =20 > allowing OS to change BootOrder and reverting. Boot#### may contain crit= ical 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=20 > huge. Can a platform module run at a different point of time to manage t= he 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=20 > 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