Are the On-Die Root of Trust and SEC2 security microcontroller physically the same thing?

Accelerated Computing Confidential Computing
1

In a public GTC 2023 Video, I noticed the Hopper series has an On-Die Root of Trust and an SEC2 security microcontroller for confidential computing.

  • Root of Trust (RoT) seems to be the trust anchor for RTR/RTS/RTM.
  • SEC2, a security microcontroller, seems to be used as CC mode GPU decryption engine.
    Typically, we trust the RoT, but we need a ‘chain of trust’ if SEC2 is another component.

My question: Are the RoT and SEC2 physically the same thing? What is their relationship?

2

The chain of trust is roughly CEC EROT (if present) → FSP → GSP → SEC2, where FSP, GSP, and SEC2 are all RISC-V microcontrollers that reside on the H100 chip. So RTR and RTM is the CEC EROT. RTS is its own hardware subsystem, basically just registers whose measurements can be extended.

3

Thanks!
That is to say, the CEC EROT acts as RTR who signs the report, while we use GSP as SPDM Responder on Hopper who generate the SPDM MEASUREMENTS response messages (by fetching the signed report), correct?

What is the meaning of ‘CEC’ and ‘E’ in CEC EROT, and FSP = First Stage processor?

4

who signs the report

No, it authenticates and loads FSP’s firmware. FSP also has its own bootROM so it is doubly authenticated. See https://youtu.be/NO3l9QhpbzQ for how the attestation key is derived.

What is the meaning of ‘CEC’

‘E’

External.

FSP

Foundation Security Processor.

1 Like
5

Thanks for the provided reference. I am familiar with the DICE spec, but I still have questions:

The “on-die” vs. “external” RoT

As claimed in the public reference, Hopper has on-die RoT, while the CEC is a separate chip on board. I believe they can’t be the same thing. Perhaps the FSP is the on-die RoT, and the CEC EROT is another platform-level one?

Which component is the RTR that signs the report?

In your reference talk, I noticed the RTR and SPDM Responder work in the Firmware layer (Perhaps SMC, GSP FW). Given the GSP as an SPDM Responder, RTR should also be an on-die component, correct?

RTR co-locates with the SPDM Responder on the GSP
RTR co-locates with the SPDM Responder on the GSP1890×1156 96.4 KB

6

Like I said, the EROT and the FSP bootROM both authenticate FSP’s firmware, so there’s both external and internal authentication. EROT comes up first and authenticates first, so it is more fundamental / rooty.

For SPDM message signing, GSP has an SPDM partition and an Attestation partition. (See https://youtu.be/l7i1kfHvWNI on how partitions work.) SPDM partition handles SPDM message parsing and message generation and Attestation partition signs the message.

RTR should also be an on-die component, correct?

If you think FSP’s bootROM is entirely equivalent in function and security to the CEC’s bootROM, then sure you can say the FSP bootROM is the RTR / RTM and is on-die. But since EROT comes up first and kicks everything off I consider it to be the RTR / RTM.

7

Why introduce EROT since FSP is able to work as RTR / RTM ?

8

The EROT owns the onboard FLASH and is the root of trust for FLASH update. Since it owns update it makes sense that it would also own reading and authenticating FLASH contents. In addition it provides out-of-band attestation of itself and the FLASH contents as an SPDM Responder.

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.