From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx.groups.io with SMTP id smtpd.web11.5773.1600403263930406033 for ; Thu, 17 Sep 2020 21:27:44 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=I+TrpBDw; spf=pass (domain: intel.com, ip: 192.55.52.93, mailfrom: ray.ni@intel.com) IronPort-SDR: aQqJ3oiRXe6rpUCIyRVjET1/Pcw/8LWpeW3Zij2YzRb4aBaFjisUZRa5QScmO1QrGj9rto5KLT G6ymPzGIolQw== X-IronPort-AV: E=McAfee;i="6000,8403,9747"; a="157252526" X-IronPort-AV: E=Sophos;i="5.77,273,1596524400"; d="scan'208,217";a="157252526" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 21:27:41 -0700 IronPort-SDR: MDvGkZDBgosBmk7AQzXNW1I3Mqw1fSyEQCZrgQi5LXMY3J/RQg3VHd6XPeEbABj9cUYBOtmKE4 hX5AUgVUGhLw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,273,1596524400"; d="scan'208,217";a="289216621" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga008.fm.intel.com with ESMTP; 17 Sep 2020 21:27:40 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 17 Sep 2020 21:27:39 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 17 Sep 2020 21:27:39 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.173) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 17 Sep 2020 21:27:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m4+UutrTmS2V+9tGIbZJ25nsoFOxct75XZ3rluBNn4o0CEs9L+0qeA8irWDrCUzYYfxyUHgjHGxa4Mj17pZ1VIIBHGNxioJzm8SGpj7eufS7bp95ORONPD9tWXCW0u1U6Z+Z1SYIsXseHJY5jyBFzpebRZPQbyT9iN7EMbdbmt5k8BCTaslSSscgEQRzfZiVDwaUjn+/9z6ARyIJ+DLa2okjqCpEtoQGL/vD8jlY4hwBaRdmb3z9zDnmghWxI3L6pgJf7QAhwGzw2hglpnlwBRT1F6tb3IdoQGLiQdfnY6RKy4oanNdKx5OIMRmIaEE5W/ODuhF1aPm82XzsXdJBNg== 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=ILukj2NElMMazxKMg6PgqudrIduOi40+mPNyD+mc0Os=; b=i3nfUpTHs2RC1vAwuB9XDRjT1bPqd8vZTo35Dmb0sWps8uV4w8TwxX/JIP0OjOTMqBLAH56qv+zKBDrVx9hEZuJgrbzQ4FBB+J8GO/tUT84GWPcRmPo3NbRV65GvwwF/MXNTpu8T8T30Pg4oAVhRno3JGLKvepr629sGWxBFtzPIOigxYvbUfAZmQdmo1EdPszC824tfd+TbSZrRG3v/0qJuGr5SdpNDxspcYYYtyTRnn0ycRqOVfQgE9WjDm7ZgcciuMxo5msCpGbxCnLgQdZQtetXeVFGPUYuu+d9p8tIezdFOLvQtr0QG0YQci0KRxAqjbpzZm8zHzjI7ezxPYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ILukj2NElMMazxKMg6PgqudrIduOi40+mPNyD+mc0Os=; b=I+TrpBDwM0l1FcLBhTd5hjmeYCqm/3LuVfkdv/XTzFjYcNjFWFcDEOWdkIwjwHXcAJBmQ6J/7DHNN4Z9V/JilVe4i5nJ6B3Ptc8oiE7y9gmw5gcBDKEyJcH2OPNAANDqin49z6Qr6L5dj1kFEDachU6cABqfYoQk6KFIVXMB8EY= Received: from BY5PR11MB4007.namprd11.prod.outlook.com (2603:10b6:a03:189::28) by BYAPR11MB3189.namprd11.prod.outlook.com (2603:10b6:a03:7c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Fri, 18 Sep 2020 04:27:38 +0000 Received: from BY5PR11MB4007.namprd11.prod.outlook.com ([fe80::1533:4053:1c45:3596]) by BY5PR11MB4007.namprd11.prod.outlook.com ([fe80::1533:4053:1c45:3596%6]) with mapi id 15.20.3370.019; Fri, 18 Sep 2020 04:27:38 +0000 From: "Ni, Ray" To: "devel@edk2.groups.io" CC: "Wang, Sunny (HPS SW)" , "Rothman, Michael A" , "Aggarwal, Nivedita" , "Desimone, Nathaniel L" , "Kinney, Michael D" , "Dong, Eric" , "Wu, Hao A" , "Bi, Dandan" Subject: TianoCore Community Design Meeting Minutes - Sep 18, 2020 Thread-Topic: TianoCore Community Design Meeting Minutes - Sep 18, 2020 Thread-Index: AdaNcsVc0cP3tLG1R2OsKu70LbRp2Q== Date: Fri, 18 Sep 2020 04:27:38 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 443e8104-6bc6-4c7f-f769-08d85b8b2cc9 x-ms-traffictypediagnostic: BYAPR11MB3189: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2mgEkSJ+04glGLU1oFmaB/bH36EGF3C9zVG3+9T+jEOwJ/PCsMGt8JiExzlSxjsfcHekeNf+rzj5zlpW3D1vq0vb1GLIBio4CqMc6qqS5IBf9SkapgtwYtxdn5O7AAraeR1pAM24Noay4fCwul+wFzN9s0cWC133rpDJ+Dic4hw4OJSloYDZ0SC/IYb72WUtxPnZ0tuyuBkQTJZ49trApm732fjLZx1bHhwwMYWG3IEJAU+7iqZZZaTiGVYidizPjOVms+/c3FqZKpwWaHBbiYyiAWpcwWQ33nUK/B2MohqKvJE7LtLqnXhh3bL7ouxvRKyefWheWjj1+kGbkKKlVYlhFY1hydnMxICCqeM+dtnY/tsnx2wiIGMtlpoeU2JryLCTm3RcFuFFgccFKBDucA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR11MB4007.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(396003)(366004)(39860400002)(136003)(376002)(346002)(33656002)(6916009)(66556008)(66476007)(186003)(54906003)(64756008)(316002)(66446008)(107886003)(2906002)(6506007)(26005)(478600001)(8676002)(52536014)(66946007)(5660300002)(83380400001)(966005)(86362001)(4326008)(76116006)(8936002)(71200400001)(55016002)(9686003)(7696005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: pwVt9CwAfYF+yjhqhFRB1i9o7Rxh6ieXCUQ/tDCw+qcwOz5wygOiYCVkKjPf+UJStSHBnCzp/MdhMJV9nOkbxXNz9bpIywJowwZ3eFsSrgZuZqiARuCRW3BZEkDW8xg4kNxd9mV0ny+Mf0ccLvVXOwlTzGTb9jB8lV+iDU5G/g7HRbZUUudJz0/Wr63bEyguKSHrzV+KI/ZGMrbmSgUuwM4KEZfgmi2sLfiv0Kw7maZOmUz+WFkxiiBTJrrbcq2kTl5Cv21Sqhvj9MYLMt4q0V/C4NOsZLLg6W2NxiIxzOfsTt8YyK+sVKHQ9LUI5WncFM2zi2uuHqW0VmZHiGjY+iiJWbDmccjGzvnA/yTdEmsebbtYkfZKKz+c0TsHjtuE/pgM47PRhKI599SAgfSsai28JjjQYG5BEMSoJ1YjhIsuYzSxgHtgELal0Ul+OMtSRemym/PY7Q91LzjrC+xCOk6s1oyP65ToZDTUJjqb55TCtSBt9lCv+SxX4djGuriAcu3J2ThXz89ly2o834sf+vl+/sTkb909md9IkPyaA0PUnv+0chTQq569tYKN2X3nWtlCK6nuL82Ypu1XH4BtVYzKLbacFeiArmyYMNyLfNi3l3lBoqP45mgsEVxouIGuyMdv6bSWE8XtzzBvlLjM7A== MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4007.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 443e8104-6bc6-4c7f-f769-08d85b8b2cc9 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2020 04:27:38.0441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iPMnu5+V5chVBiGPgBVMK3FQfugiOBXmuqMaup+tbcxLjcF5V9auZh1ip2XVOTmQSElPUElX+qABT+zR/YgPVg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3189 Return-Path: ray.ni@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4007E872D6D2A8EA03D7580E8C3F0BY5PR11MB4007namp_" --_000_BY5PR11MB4007E872D6D2A8EA03D7580E8C3F0BY5PR11MB4007namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Topic: Sanitization Protocols for Option Cards (Sunny Wang / HPE) Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0918/Sanitization= %20Protocols%20for%20Option%20Cards_200918.pdf More materials @ https://edk2.groups.io/g/devel/files/Designs/2020/0918/ 1. Overview Sunny presented HPE's UEFI Spec change proposal to meet NIST SP 800-88 stan= dard, sanitizing the firmware configuration and storage devices. NIST SP 800-88: HPE as the server vendor should be compliant to this stand= ard. Option Card =3D PCI device that contains Option ROM. 2. Sanitizing firmware configuration @Liming: HII design provides mechanism to restore the default. @Nickle: Problems in HII: 1). Cannot support cases like removing iSCSI atte= mpt password. 2). Default value for some HII settings is not available. @Liming: We should follow the principle that anyone that produces the data = is responsible for clearing/sanitizing. @Nickle: The design aligns to this idea. @Ray: The requirements of clear and purge are different. Purge cannot be re= covered. Clear can. @Nate: EFI_ is reserved prefix. @Liming: Suggest to follow the code first process (https://github.com/tiano= core/tianocore.github.io/wiki/EDK-II-Code-First-Process) to use proper pref= ix. @Ray: Let's firstly see how to enhance HII design to support such requireme= nt. 3. Sanitizing storage devices @Nivedita: Internal discussion in Intel prefers to reuse BlockErase. @Sunny: Some non-block devices may also need to sanitize. BlockErase cannot= meet the needs. @Ray: An example of non-block device is the label storage in NVDIMM. @Nivedita: Existence of two protocols (BlockErase and proposed Sanitize) ca= uses a load to consumer. @Abner: Sanitize protocol is controller based, BlockErase is device based. @Kevin: Is it a security risk that any driver/application can call the prot= ocol to purge all data? @Ray: That's a good open! But even without this protocol, someone can call = Passthru protocol to send the commands to purge data. More feedbacks are we= lcomed whether the security concern needs to be considered in design level.= Option ROMs are dispatched after EndOfDxe so denying the purge/sanitize af= ter EndOfDxe is not applicable. @Abner: Another security risk is one option rom can call the protocol produ= ced by the other option rom to purge storage not owned by itself. @Ray: Two opens: 1). Let's discuss with Rothman Michael about how to conso= lidate the BlockErase and proposed Sanitize. 2). Should we consider securit= y? --_000_BY5PR11MB4007E872D6D2A8EA03D7580E8C3F0BY5PR11MB4007namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Topic: Sanitization Protocols for Option Cards (Sunn= y Wang / HPE)

 

Slides: https://edk2.groups.io/g/devel/files/Designs= /2020/0918/Sanitization%20Protocols%20for%20Option%20Cards_200918.pdf<= /o:p>

 

More materials @ https://edk2.groups.io/g/devel/file= s/Designs/2020/0918/

 

1. Overview

 

Sunny presented HPE's UEFI Spec change proposal to m= eet NIST SP 800-88 standard, sanitizing the firmware configuration and stor= age devices.

 

NIST SP 800-88:  HPE as the server vendor shoul= d be compliant to this standard.

 

Option Card =3D PCI device that contains Option ROM.=

 

      2. Sanitizing firmwar= e configuration

 

@Liming: HII design provides mechanism to restore th= e default.

@Nickle: Problems in HII: 1). Cannot support cases l= ike removing iSCSI attempt password. 2). Default value for some HII setting= s is not available.

@Liming: We should follow the principle that anyone = that produces the data is responsible for clearing/sanitizing.

@Nickle: The design aligns to this idea.<= /p>

@Ray: The requirements of clear and purge are differ= ent. Purge cannot be recovered. Clear can.

@Nate: EFI_ is reserved prefix.

@Liming: Suggest to follow the code first process (h= ttps://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Proc= ess) to use proper prefix.

@Ray: Let's firstly see how to enhance HII design to= support such requirement.

 

3. Sanitizing storage devices

 

@Nivedita: Internal discussion in Intel prefers to r= euse BlockErase.

@Sunny: Some non-block devices may also need to sani= tize. BlockErase cannot meet the needs.

@Ray: An example of non-block device is the label st= orage in NVDIMM.

@Nivedita: Existence of two protocols (BlockErase an= d proposed Sanitize) causes a load to consumer.

@Abner: Sanitize protocol is controller based, Block= Erase is device based.

@Kevin: Is it a security risk that any driver/applic= ation can call the protocol to purge all data?

@Ray: That's a good open! But even without this prot= ocol, someone can call Passthru protocol to send the commands to purge data= . More feedbacks are welcomed whether the security concern needs to be cons= idered in design level. Option ROMs are dispatched after EndOfDxe so denying the purge/sanitize after EndOfDxe= is not applicable.

@Abner: Another security risk is one option rom can = call the protocol produced by the other option rom to purge storage not own= ed by itself.

@Ray:  Two opens: 1). Let's discuss with Rothma= n Michael about how to consolidate the BlockErase and proposed Sanitize. 2)= . Should we consider security?

--_000_BY5PR11MB4007E872D6D2A8EA03D7580E8C3F0BY5PR11MB4007namp_--