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.