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.

@Nickle: The design aligns to this idea.

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

@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.

@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?

@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.

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