Streaming Boot policy, FW encryption and FW download

[rstrongMCT]

Streaming boot as defined in Caliptra 2.x seems to indicate Caliptra FW and MCU must be provided via streaming boot boot. The flow fragment from the specification illustrates this:

1. SoC manifest is streamed next using the streaming boot protocol, which Caliptra authenticates & measures
2. This is followed by MCU RT FW through the streaming boot protocol which Caliptra routes to MCU SRAM, authorizes and activates MCU to execute it.
3. MCU RT FW will go through MCTP enumeration and fetch the remaining SoC blobs (FW, data etc.) using DSP0267 PLDM for Firmware Update over MCTP and uses Caliptra to authorize each of them.

Is it possible to define policy bits (eFuse based) that indicate:
• Enable streaming boot for both SoC and Caliptra
• Enable hybrid boot: streaming boot for Caliptra only, normal flash boot for SoC (non-streaming)
• Enable passive boot for both Caliptra and SoC

Rationale:
• Allows maximum design flexibility: provides an incremental support path for SoC designs to eventually support full Caliptra 2.x + streaming support.
• Flexible support for environments that have a BMC (or equivalent) with streaming boot support and environments that do not have BMC (or equivalent) streaming support. It may take some time for the ecosystem to transition to full Caliptra 2.x + streaming boot support.

Additional questions:

1. Streaming boot does not describe how FW encryption is to be supported. Per OCP Datacenter NVMe® SSD Specification Version 2.6:
   o SEC-40 All device firmware packages shall be encrypted based on a symmetric encryption algorithm. See SEC-2 for acceptable algorithms and SEC-29 for key storage requirements
   o SEC-42 The device shall only store firmware in encrypted format when stored in non-volatile memory
   Why encrypt? Protect IP and prevent bad actors from discovering vulnerabilities in the FW. Since Caliptra FW is open source, there isn’t necessarily a compelling reason to encrypt it. With streaming boot this remains true for Caliptra core FW. However, SoC provided FW intended to execute on the MCU may have expectations that it be encrypted (for the IP and inspection for vulnerabilities as previously noted).

If the assumption is that the BMC decrypts the FW image prior to delivery to Caliptra and MCU, will this meet the spirit of the requirement? Since I3C can technically be snooped, this may not fully meet the DataCenter spec requirements in which case Caliptra may be required to perform MCU FW decryption using an eFuse based key?

2. If streaming boot is enabled, there is no mention of how the device responds if the host attempts a firmware download. For a NVMe storage device this includes Firmware Image Download and Firmware Commit commands.
   o For Firmware Image Download, no action needed.
   o For Firmware Commit, fail with: Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons?