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.web10.2840.1581072268235107093 for ; Fri, 07 Feb 2020 02:44:28 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.147.86, mailfrom: prvs=0306f3627f=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 017AbrrK015182; Fri, 7 Feb 2020 10:44:27 GMT Received: from g9t5009.houston.hpe.com (g9t5009.houston.hpe.com [15.241.48.73]) by mx0a-002e3701.pphosted.com with ESMTP id 2y14gnrya3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Feb 2020 10:44:27 +0000 Received: from G2W6309.americas.hpqcorp.net (g2w6309.austin.hp.com [16.197.64.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5009.houston.hpe.com (Postfix) with ESMTPS id 6E1F55B; Fri, 7 Feb 2020 10:44:26 +0000 (UTC) Received: from G9W8454.americas.hpqcorp.net (2002:10d8:a104::10d8:a104) by G2W6309.americas.hpqcorp.net (2002:10c5:4033::10c5:4033) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 7 Feb 2020 10:44:25 +0000 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (15.241.52.12) by G9W8454.americas.hpqcorp.net (16.216.161.4) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 7 Feb 2020 10:44:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Akp+RuzcTHrWW0CUU2IiGEXU4ElZTfFtNJeFRYm1mrZuF4eRvNEH4a9Ll/KWPPYK0umGxti5aFX2517iy/YTG4uQLKPxAZ08JFbxZw6NxUPxT5D+u/j4sZyr3JehyZRTXY8fy2URxx4L2379IesIMkY2q3ypIzyIq0cZapJVACeaSIzrW93yqFsQcBYnZoIdyLLSPLf41fyt0ytKOPK64eO4tTAPPGonP3HB0JIe5erUQ5KOB912qEFDTkjw1QQVTAobDGgmtf0xE/Nw9fvWIQxvXWTjTVaCelNAH4HY69Q37YhPnTlvUXDHdwqgTHGZiMT8ZVzIlUoIAkyM2kCP9Q== 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=BSV+FM9FhUT28v3s76+hI6aed0X2Y11oxvn4P5Qb8bc=; b=NyExzZvcEjgRoZIiLGcj6AY/rz2u3Nzl0oeI1Iqt9s8aKArgbmJ5DEDaVj469U66QBLfHuIUKVmJfMVv9xyckVrfvCJExnB6v4HB9Lbx3mL9rkMJL+vNVyKHVEAc5tg7u9wIz+i4VpZkZYddTPvwlxDQL7C9c1Abx7bj3Al6xkYHnKP+tg57NMH31DQLWflNWr5qniOUv/Gn7dLXhB/JhJRc1B07PcgxY2Amb+DtVvygQuCYGmLqMnt9KQ6jhm6Dt26Gt9vjH2s/AQ77YPBmeo0y21Msrk886umfZalUOgZ5LBKURf7orZ6zkAIjqcLOJV7SKySe96jPfKdLiDOgHg== 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 (10.169.84.149) by DF4PR8401MB0794.NAMPRD84.PROD.OUTLOOK.COM (10.169.83.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.26; Fri, 7 Feb 2020 10:44:24 +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.2707.024; Fri, 7 Feb 2020 10:44:24 +0000 From: "Wang, Sunny (HPS SW)" To: "rfc@edk2.groups.io" , "bret.barkelew@microsoft.com" , Jiewen , "devel@edk2.groups.io" , "Wang, Sunny (HPS SW)" CC: "Spottswood, Jason" , "Wiginton, Scott" Subject: Re: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative Thread-Topic: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative Thread-Index: AQHV1ji67UKQxsv360e3bB8BQsJIDqgPdNIw Date: Fri, 7 Feb 2020 10:44:24 +0000 Message-ID: References: In-Reply-To: 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: 1e780167-5a89-48a3-d061-08d7abbab28a x-ms-traffictypediagnostic: DF4PR8401MB0794: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:628; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(136003)(366004)(376002)(396003)(346002)(39860400002)(189003)(199004)(5660300002)(7696005)(52536014)(478600001)(86362001)(966005)(8936002)(8676002)(81166006)(81156014)(2906002)(33656002)(53546011)(6506007)(26005)(316002)(110136005)(54906003)(66476007)(66556008)(66446008)(64756008)(76116006)(66946007)(4326008)(9686003)(55016002)(186003)(71200400001);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR8401MB0794;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: j+1I2xcJoN2mpmgmzOQ99JRYIF478GW+dVAwDk1z2avB+d8iAklm3NtjmL4wJilri5//6qVUWEmKxEJmxJEYuQdKlQhSADItef9nK4vRRMf+MuuE1E4BT9fEJIUj9GDaQRtooO/v3ifvAJLKsOaZhKnxDt42LPeTM8GEACLxw6bgjVp76pZAjmvNdx10/d3XygpuIFQYg5wRbGDkDUpnJFfRyOGFb2rWu21n7lPH9VkCeboeBhbHaJE39UxS+lsa5jsvG3WSsd4DBn0AQwAcUcJupNbUw7/WYJsMoaQcAWFyv2taXX1eT50KxskOqJH5wjDcKq1RUsiXheWfU4EuIWkC8Rnv6gDCdzDDojybhK5Lfv4DeMkt/E5G0/lPxl4Qe7onjuhUP3GtjoZdr0owJLQC6437xU/LEw60OFsCh3iOg/KViCPQfxS/wzgejNKKIwjONMw6OfnMZrfdtkqn+OtsZ9kmVCxybssyzFrmGu5gdktpPlp7jYT1F0wGfvrPFv99YDDv7FKNezCmLHwcGA== x-ms-exchange-antispam-messagedata: 02VBLpfNiAuyolRcGzAxJZC9iGIfNTtjOWJKCg6kzT/fHlXtn8LoWWvmWD2KH14rR7y1Bq/Faf0G1o/rGUJ6TYwUeeX5t6iyzJc7m99s6wvBejlHX3XliBX58ZDbuRuJot8pTIIU/adKO1qI1Ztzug== X-MS-Exchange-CrossTenant-Network-Message-Id: 1e780167-5a89-48a3-d061-08d7abbab28a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 10:44:24.2763 (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: FSRf5sZdREuR6PZEmNwYgQhLJejKzD+byAF0zgoBfHDRPKFlQLD+Pd3vbzpMUYwHE1QfsMi9sQwzsp0J6Yj8qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0794 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 3 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-02-07_01:2020-02-07,2020-02-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 clxscore=1011 malwarescore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002070082 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bret,=20 Your proposal looks good to me, and most of my questions/concerns were alr= eady answered/solved by the GOOD discussion between you and Jiewen. For now, I just have one remaining question. Can we also make DumpVariable= Policy as a platform choice?=20 DumpVariablePolicy would also expose the information about how to pass the= check to the attacker. If my understanding is correct, the attacker can ev= en use the information to unlock the variable locked by LOCK_ON_VAR_STATE t= ype policy. Therefore, If the DumpVariablePolicy is just to allow platform = tests to audit the entire policy list, can we add a PCD or a build flag che= ck to disable it in release build? Of course, I also agree with Jiewen's po= int about making DisableVarPolicy as a platform choice. By the way, I had the other question that I already got the answer from th= e code and your document. Since it hasn't been discussed, I think it would = be good to share the answer with others. The question is how VariablePolicy= deals with the multiple RegisterVariablePolicy calls with the same variabl= e name and GUID. The answer is that the first registered policy will be the= winner. The later calls (from attackers) with the same name and GUID will = just get EFI_ALREADY_STARTED and fail to register the compromised policy. T= herefore, RegisterVariablePolicy looks good to me as well.=20 Regards, Sunny Wang -----Original Message----- From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Bret Bar= kelew via Groups.Io Sent: Wednesday, January 29, 2020 9:36 AM To: rfc@edk2.groups.io Subject: [edk2-rfc] [RFC] VariablePolicy - Protocol, Libraries, and Implem= entation for 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