Hi Jackson,

Thanks for fast response.

I shall combine the points requested in your previous reply with the questions that have arisen while reviewing the code since then, and respond accordingly.

1. TF-A has APIs for using Host RoTPKs stored in RSE TF-M. These calls are classified by enum in platform/ext/target/arm/rse/common/platform_builtin_key_loader_ids.h. Then I found out that some changes happened in this code.

(If uploaded images aren't shown, please let me know. This image is about code change of platform_builtin_key_loader_ids.h.)

That's the point that I asked before. However, in this code, RSE_ROTPK_CM_HOST_AMOUNT and RSE_ROTPK_DM_HOST_AMOUNT are only defined in platform/ext/target/arm/rse/common/subplatform_pal_default_config/rse_rotpk_config.h.

I understand that one CM ROTPK and two DM ROTPK substitute previous Host RotPKs, but don't understand why. I think this part is for Chain-of-Trust in whole firmware stack including TF-A, TF-M and TF-RMM.

- Is it acceptable to use that ROTPKs as trust anchors for the Host's CoT, as was done previously?

- Is this definition used as-is during the build process, located in the subplatform folder for the quantity of the relevant ROTPK?

- What is the purpose of the 'subplatform' definition?

2. There were several CCA assets in the provisioning bundle. These assets include implementation identifier, platform definition, and verification service URL. I can't find field for these assets in the OTP layout in TF-Mv.2.2.2. 

Have they completely disappeared? Otherwise, how can it be set? I'm a bit embarrassed that they're not visible.

I'm always grateful for your efforts in maintaining this project.

I realise that waiting for the next version of RDINFRA might actually be the better answer, but I wish to understand the code without relying on that.

Thank you.

----- 원본 메시지 -----
보낸 사람: Jackson Cooper-Driver via TF-M <tf-m@lists.trustedfirmware.org>
받는 사람: 김태훈 <gth1919@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
날짜: 2025-12-12 19:28:53
제목: [TF-M] Re: Several Questions related to RSE Provisioning

Hi TH Kim,

Thanks for getting in touch, please see my answers below.

Thanks,

Jackson

From: 김태훈 via TF-M <tf-m@lists.trustedfirmware.org>
Date: Thursday, 11 December 2025 at 16:40
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Several Questions related to RSE Provisioning

Hello, I'm a RSE firmware developer for Arm Neoverse V3 core.

I am currently reviewing the code to upgrade the version of TF-M used in our product from 2.1.1 to 2.2.2. In this process, I have a few questions and am sending this email.

1. In the previous TF-Mv2.1.1, there were dummy files for the data structure of the bundle to be provisioned to the OTP during CM and DM state. I have discovered that the method for creating the bundle has changed significantly in the TF-Mv2.2.2, but there are still parts I cannot locate: Host RoTPKs (for secure, non-secure, and CCA). This parts were provisioned during the DM provisioning process in the TF-Mv2.1.1 with a size of each 96B. I am curious how this parts are implemented in 2.2.2.

>> In TF-Mv2.2.2, we currently only provision a small number of the CM ROTPK slots and do not provision any DM ROTPKs. It is possible that we might decide to add more ROTPKs in the future for use by the host, but that is not currently implemented. The keys themselves would be specific to the platform.

1-1. When TF-A sends a PSA call to the RSE, it distinguishes which Host RoTPK to request from the RSE via persistent key identifiers. I am also curious about how this aspect is handled within the RSE TF-M. (Should this fall outside the scope of the TF-M project, please disregard this point.)

>> Can you point me to the code that does this in TF-A and then I can help you trace it back to how the RSE handles this?

2. In the latest TF-Mv2.2.2, as mentioned earlier, the data structure for the Provisioning value appears to have undergone significant changes. Reviewing the code, I observed that the CM and DM Provisioning values contain multiple RoTPK areas. Some are used to verify the signatures of the BL2 and PE, but many are not. Are the unused fields simply reserved for future use, or spares? Each area can contain up to four RoTPK Hashes, and in the case of DM, there are as many as eight such areas, which appears to be a significant waste of space. I would like to understand what scenarios this design anticipates.

>> The intention of the additional ROTPK arrays is to allow for key revocation should a key become compromised. Should this be required, then the entire array (of up to four hashes) will be revoked and a new array provisioned. Additional unused key slots within a single ROTPK array are reserved for potential future use.

3. To obtain information about RSE, I have been referring to the content of the official documentation. However, when comparing it to the current latest release, the documentation appears to remain based on a previous version. For example, For example, despite the code for the GPIO signal indicating the status for RSE Provisioning having been removed in the latest version, the documentation still retains that content. I would like to know specifically whether there are plans to update this documentation.

>> Apologies for this, we have been slow to update the RSE public documentation. Please do continue to point out any issues and we will update them. We are updating the docs piecemeal and it is a slow process. Please bear with us on this.

Truthfully, I suspect all these questions could be answered by better understanding the code, which makes me hesitant to send an email. However, due to various constraints, I kindly ask for your understanding regarding my posting this query on the forum.

Thank you.

Best Regard,

TH Kim

Best Regard,

TH Kim