<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> I have some comments for the items below…. And a proposed solution, I think.<o:p></o:p> <o:p> </o:p> <div> Thanks,<o:p></o:p> Mike Rothman <o:p></o:p> (迈克罗斯曼 / माइकल रोथ्मेन् / Михаил Ротман / משה רוטמן)<o:p></o:p> רועה עיקרי של חתולים<o:p></o:p> </div> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Ni, Ray <ray.ni@intel.com> Sent: Thursday, September 17, 2020 9:28 PM To: devel@edk2.groups.io Cc: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Rothman, Michael A <michael.a.rothman@intel.com>; Aggarwal, Nivedita <nivedita.aggarwal@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Dong, Eric <eric.dong@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com> Subject: TianoCore Community Design Meeting Minutes - Sep 18, 2020<o:p></o:p> </div> </div> <o:p> </o:p> Topic: Sanitization Protocols for Option Cards (Sunny Wang / HPE)<o:p></o:p> <o:p> </o:p> Slides: <a href="https://edk2.groups.io/g/devel/files/Designs/2020/0918/Sanitization%20Protocols%20for%20Option%20Cards_200918.pdf"> https://edk2.groups.io/g/devel/files/Designs/2020/0918/Sanitization%20Protocols%20for%20Option%20Cards_200918.pdf</a><o:p></o:p> <o:p> </o:p> More materials @ <a href="https://edk2.groups.io/g/devel/files/Designs/2020/0918/"> https://edk2.groups.io/g/devel/files/Designs/2020/0918/</a><o:p></o:p> <o:p> </o:p> 1. Overview<o:p></o:p> <o:p> </o:p> Sunny presented HPE's UEFI Spec change proposal to meet NIST SP 800-88 standard, sanitizing the firmware configuration and storage devices.<o:p></o:p> <o:p> </o:p> NIST SP 800-88: HPE as the server vendor should be compliant to this standard.<o:p></o:p> <o:p> </o:p> Option Card = PCI device that contains Option ROM.<o:p></o:p> <o:p> </o:p> 2. Sanitizing firmware configuration<o:p></o:p> <o:p> </o:p> @Liming: HII design provides mechanism to restore the default.<o:p></o:p> @Nickle: Problems in HII: 1). Cannot support cases like removing iSCSI attempt password. 2). Default value for some HII settings is not available.<o:p></o:p> @Liming: We should follow the principle that anyone that produces the data is responsible for clearing/sanitizing.<o:p></o:p> <o:p> </o:p> Agree with this.<o:p></o:p> <o:p> </o:p> @Nickle: The design aligns to this idea.<o:p></o:p> @Ray: The requirements of clear and purge are different. Purge cannot be recovered. Clear can.<o:p></o:p> <o:p> </o:p> Yes, but if we are talking about HII menuing features, such as through the setup browser, various action buttons could trigger custom responses via callbacks into the driver. This would be no different in concept to triggering the desire to Format a raid array. HII has no concept of that, but it’s supported via a cooperation between the browser triggering a callback based on the user selection of a custom action op-code and the driver that services that callback. So a menu could contain a clear and/or purge command, it’s just dependent on the design of the IFR pages and driver. I would also note that we have a standard EFI_RESET_BUTTON_OP which sounds like a Clear operation. <o:p></o:p> I thought about the possibility of adding a purge operation as a new op-code, but it doesn’t really make sense to me since purging alone may very well leave the device’s configuration in an invalid state, and a restore to defaults would need to be done immediately after the purge so that we at least have a working configuration that has been purged. Both of those operations could be described and done via the EFI_RESET_BUTTON_OP operation. There might be some clarifications we could do to the spec, but I’m wondering – isn’t it the purview of the driver implementation that services the reset to actually KNOW what the policy is for that device and whether or not a reset actually means a clear and then reset, or a purge and then reset? I think it is. <o:p></o:p> <o:p> </o:p> @Nate: EFI_ is reserved prefix.<o:p></o:p> @Liming: Suggest to follow the code first process (<a href="https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process">https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process</a>) to use proper prefix. <o:p></o:p> @Ray: Let's firstly see how to enhance HII design to support such requirement.<o:p></o:p> <o:p> </o:p> 3. Sanitizing storage devices<o:p></o:p> <o:p> </o:p> @Nivedita: Internal discussion in Intel prefers to reuse BlockErase.<o:p></o:p> @Sunny: Some non-block devices may also need to sanitize. BlockErase cannot meet the needs.<o:p></o:p> @Ray: An example of non-block device is the label storage in NVDIMM.<o:p></o:p> <o:p> </o:p> I agree – so, similar to what we did in EraseBlock, I would suggest we extend the label storage protocol – something such as:<o:p></o:p> <o:p> </o:p> #define EFI_NVDIMM_LABEL_PROTOCOL2_GUID \ {0xc2f67a65,0x9d98,0x4608, \<o:p></o:p> {0x98,0xe3,0x83,0x90,0x57,0x51,0xd1,0x04}}<o:p></o:p> <o:p> </o:p> typedef struct _EFI_NVDIMM_LABEL_PROTOCOL2 { EFI_NVDIMM_LABEL_STORAGE_INFORMATION LabelStorageInformation; EFI_NVDIMM_LABEL_STORAGE_READ LabelStorageRead; EFI_NVDIMM_LABEL_STORAGE_WRITE LabelStorageWrite; EFI_NVDIMM_LABEL_STORAGE_ERASE Erase; }<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <a name="_Toc474841551">EFI_NVDIMM_LABEL_PROTOCOL.Erase()</a><o:p></o:p> Summary<o:p></o:p> Erase the label data for the Label Storage Area that is associated with a specific NVDIMM Device Path.<o:p></o:p> Prototype<o:p></o:p> typedef EFI_STATUS (EFIAPI *EFI_NVDIMM_LABEL_STORAGE_ERASE) ( IN CONST EFI_NVDIMM_LABEL_PROTOCOL *This, IN EFI_LABEL_ERASE_TYPE EraseType );<o:p></o:p> Parameters<o:p></o:p> This A pointer to the EFI_NVDIMM_LABEL_PROTOCOL instance.<o:p></o:p> EraseType The type of erase that should be completed on the Label Storage Area for the NVDIMM. <o:p></o:p> <o:p> </o:p> Description<o:p></o:p> Erase the data per the method specified by EraseType for the Label Storage Area for the NVDIMM. See the Label Index Block and Label Definitions sections below for details on the contents of the label data.<o:p></o:p> typedef enum {<o:p></o:p> Overwrite,<o:p></o:p> BlockErase,<o:p></o:p> CryptoErase<o:p></o:p> } EFI_LABEL_ERASE_TYPE;<o:p></o:p> <o:p> </o:p> Overwrite The Overwrite sanitize operation alters user data by writing a fixed data pattern or related patterns to all locations on the label storage area within the NVM subsystem in which user data may be stored one or more times. The parameters LBA and Size are ignored if this operation is used.<o:p></o:p> <o:p> </o:p> BlockErase The Block Erase sanitize operation alters user data with a low-level block erase method that is specific to all locations on the label storage area within the NVM subsystem in which user data may be stored. The parameters LBA and Size are ignored if this operation is used. <o:p></o:p> <o:p> </o:p> CryptoErase The Crypto Erase sanitize operation alters user data by changing the media encryption keys for all locations on the label storage area within the NVM subsystem in which user data may be stored. The parameters LBA and Size are ignored if this operation is used.<o:p></o:p> <o:p> </o:p> Status Codes Returned<o:p></o:p> <o:p> </o:p> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse"> <tbody> <tr> <td width="200" style="width:150.0pt;border:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt"> EFI_UNSUPPORTED<o:p></o:p> </td> <td width="200" style="width:150.0pt;border:solid windowtext 1.0pt;border-left:none;padding:0in 5.4pt 0in 5.4pt"> The device cannot support the requested EraseType operation.<o:p></o:p> </td> </tr> </tbody> </table> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> @Nivedita: Existence of two protocols (BlockErase and proposed Sanitize) causes a load to consumer.<o:p></o:p> @Abner: Sanitize protocol is controller based, BlockErase is device based.<o:p></o:p> @Kevin: Is it a security risk that any driver/application can call the protocol to purge all data?<o:p></o:p> <o:p> </o:p> No current concept of privilege accesses – anyone can do anything.<o:p></o:p> <o:p> </o:p> @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 welcomed whether the security concern needs to be considered in design level. Option ROMs are dispatched after EndOfDxe so denying the purge/sanitize after EndOfDxe is not applicable.<o:p></o:p> @Abner: Another security risk is one option rom can call the protocol produced by the other option rom to purge storage not owned by itself.<o:p></o:p> <o:p> </o:p> See above.<o:p></o:p> <o:p> </o:p> @Ray: Two opens: 1). Let's discuss with Rothman Michael about how to consolidate the BlockErase and proposed Sanitize. 2). Should we consider security?<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Below is what we came up with for EraseBlock:<o:p></o:p> typedef struct _EFI_ERASE_BLOCK_PROTOCOL { UINT64 Revision; UINT32 EraseLengthGranularity; EFI_BLOCK_ERASE EraseBlocks; EFI_BLOCK_ERASE_EX EraseBlocksEx; } EFI_ERASE_BLOCK_PROTOCOL;<o:p></o:p> <o:p> </o:p> typedef<o:p></o:p> EFI_STATUS<o:p></o:p> (EFIAPI *EFI_BLOCK_ERASE_EX) (<o:p></o:p> IN EFI_ERASE_BLOCK_ PROTOCOL *This,<o:p></o:p> IN UINT32 MediaId,<o:p></o:p> IN EFI_LBA LBA,<o:p></o:p> IN OUT EFI_ERASE_BLOCK_TOKEN *Token,<o:p></o:p> IN UINTN Size,<o:p></o:p> IN EFI_ERASE_BLOCK_PROGRESS Progress, OPTIONAL<o:p></o:p> IN EFI_ERASE_TYPE EraseType<o:p></o:p> );<o:p></o:p> <o:p> </o:p> Revision = #define EFI_ERASE_BLOCK_PROTOCOL_REVISION ((2<<16) | (90))<o:p></o:p> <o:p> </o:p> IN EFI_ERASE_BLOCK_PROGRESS Progress<o:p></o:p> <o:p> </o:p> Progress A function used by the driver to report the progress of the firmware update.<o:p></o:p> <o:p> </o:p> EraseType The type of erase being requested.<o:p></o:p> <o:p> </o:p> typedef enum { Clear,<o:p></o:p> Overwrite,<o:p></o:p> BlockErase,<o:p></o:p> CryptoErase<o:p></o:p> } EFI_ERASE_TYPE;<o:p></o:p> <o:p> </o:p> Clear The Clear operation alters user data by writing a fixed data pattern or related patterns to a starting LBA location for Size number of bytes on the media within the NVM subsystem in which user data may be stored one or more times.<o:p></o:p> <o:p> </o:p> Overwrite The Overwrite sanitize operation alters user data by writing a fixed data pattern or related patterns to all locations on the media within the NVM subsystem in which user data may be stored one or more times. The parameters LBA and Size are ignored if this operation is used.<o:p></o:p> <o:p> </o:p> BlockErase The Block Erase sanitize operation alters user data with a low-level block erase method that is specific to the media for all locations on the media within the NVM subsystem in which user data may be stored. The parameters LBA and Size are ignored if this operation is used. <o:p></o:p> <o:p> </o:p> CryptoErase The Crypto Erase sanitize operation alters user data by changing the media encryption keys for all locations on the media within the NVM subsystem in which user data may be stored. The parameters LBA and Size are ignored if this operation is used.<o:p></o:p> <o:p> </o:p> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse"> <tbody> <tr> <td width="200" style="width:150.0pt;border:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt"> EFI_UNSUPPORTED<o:p></o:p> </td> <td width="200" style="width:150.0pt;border:solid windowtext 1.0pt;border-left:none;padding:0in 5.4pt 0in 5.4pt"> The device cannot support the requested EraseType operation.<o:p></o:p> </td> </tr> </tbody> </table> <o:p> </o:p> typedef EFI_STATUS (EFIAPI *EFI_ERASE_BLOCK_PROGRESS) (<o:p></o:p> IN UINTN Completion<o:p></o:p> );<o:p></o:p> <o:p> </o:p> Completion A value between 1 and 100 indicating the current completion progress of the erase operation. Completion progress is reported as from 1 to 100 percent. A value of 0 is used by the driver to indicate that progress reporting is not supported<o:p></o:p> <o:p> </o:p> On EFI_SUCCESS, EraseBlocksEx () continues to do the callback if supported. On NOT EFI_SUCCESS, EraseBlocksEx () discontinues the callback and completes the update and returns.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html> <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links: You receive all messages sent to this group. <a target="_blank" href="https://edk2.groups.io/g/devel/message/65573">View/Reply Online (#65573)</a> | | <a target="_blank" href="https://groups.io/mt/76925023/1813853">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a> <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a> [edk2-devel-archive@redhat.com] <div width="1" style="color:white;clear:both">_._,_._,_</div>