* Re: TianoCore Community Design Meeting Minutes - Sep 18, 2020
2020-09-18 4:27 TianoCore Community Design Meeting Minutes - Sep 18, 2020 Ni, Ray
@ 2020-09-24 18:40 ` Rothman, Michael A
0 siblings, 0 replies; 2+ messages in thread
From: Rothman, Michael A @ 2020-09-24 18:40 UTC (permalink / raw)
To: Ni, Ray, devel@edk2.groups.io
Cc: Wang, Sunny (HPS SW), Aggarwal, Nivedita, Desimone, Nathaniel L,
Kinney, Michael D, Dong, Eric, Wu, Hao A, Bi, Dandan
[-- Attachment #1: Type: text/plain, Size: 10057 bytes --]
I have some comments for the items below…. And a proposed solution, I think.
Thanks,
Mike Rothman
(迈克 罗斯曼 / माइकल रोथ्मेन् / Михаил Ротман / משה רוטמן)
רועה עיקרי של חתולים
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
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 standard, sanitizing the firmware configuration and storage devices.
NIST SP 800-88: HPE as the server vendor should be compliant to this standard.
Option Card = 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 attempt 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.
Agree with this.
@Nickle: The design aligns to this idea.
@Ray: The requirements of clear and purge are different. Purge cannot be recovered. Clear can.
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.
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.
@Nate: EFI_ is reserved prefix.
@Liming: Suggest to follow the code first process (https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process) 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 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.
I agree – so, similar to what we did in EraseBlock, I would suggest we extend the label storage protocol – something such as:
#define EFI_NVDIMM_LABEL_PROTOCOL2_GUID \
{0xc2f67a65,0x9d98,0x4608, \
{0x98,0xe3,0x83,0x90,0x57,0x51,0xd1,0x04}}
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;
}
EFI_NVDIMM_LABEL_PROTOCOL.Erase()
Summary
Erase the label data for the Label Storage Area that is associated with a specific NVDIMM Device Path.
Prototype
typedef
EFI_STATUS
(EFIAPI *EFI_NVDIMM_LABEL_STORAGE_ERASE) (
IN CONST EFI_NVDIMM_LABEL_PROTOCOL *This,
IN EFI_LABEL_ERASE_TYPE EraseType
);
Parameters
This A pointer to the EFI_NVDIMM_LABEL_PROTOCOL instance.
EraseType The type of erase that should be completed on the Label Storage Area for the NVDIMM.
Description
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.
typedef enum {
Overwrite,
BlockErase,
CryptoErase
} EFI_LABEL_ERASE_TYPE;
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.
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.
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.
Status Codes Returned
EFI_UNSUPPORTED
The device cannot support the requested EraseType operation.
@Nivedita: Existence of two protocols (BlockErase and proposed Sanitize) causes 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 protocol to purge all data?
No current concept of privilege accesses – anyone can do anything.
@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.
@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.
See above.
@Ray: Two opens: 1). Let's discuss with Rothman Michael about how to consolidate the BlockErase and proposed Sanitize. 2). Should we consider security?
Below is what we came up with for EraseBlock:
typedef struct _EFI_ERASE_BLOCK_PROTOCOL {
UINT64 Revision;
UINT32 EraseLengthGranularity;
EFI_BLOCK_ERASE EraseBlocks;
EFI_BLOCK_ERASE_EX EraseBlocksEx;
} EFI_ERASE_BLOCK_PROTOCOL;
typedef
EFI_STATUS
(EFIAPI *EFI_BLOCK_ERASE_EX) (
IN EFI_ERASE_BLOCK_ PROTOCOL *This,
IN UINT32 MediaId,
IN EFI_LBA LBA,
IN OUT EFI_ERASE_BLOCK_TOKEN *Token,
IN UINTN Size,
IN EFI_ERASE_BLOCK_PROGRESS Progress, OPTIONAL
IN EFI_ERASE_TYPE EraseType
);
Revision = #define EFI_ERASE_BLOCK_PROTOCOL_REVISION ((2<<16) | (90))
IN EFI_ERASE_BLOCK_PROGRESS Progress
Progress
A function used by the driver to report the progress of the firmware update.
EraseType
The type of erase being requested.
typedef enum {
Clear,
Overwrite,
BlockErase,
CryptoErase
} EFI_ERASE_TYPE;
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.
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.
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.
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.
EFI_UNSUPPORTED
The device cannot support the requested EraseType operation.
typedef
EFI_STATUS
(EFIAPI *EFI_ERASE_BLOCK_PROGRESS) (
IN UINTN Completion
);
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
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.
[-- Attachment #2: Type: text/html, Size: 38965 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread