Hello,
I would like to clarify the intended REM extend behavior, as DEN0137
2.0-bet3 and TF-RMM appear to differ.
Section B3.122, RemExtend, defines the hash input as a fixed 1024-bit
value:
old_REM[64 bytes] ||
new_value[0:size] ||
zero_padding[0:64-size]
However, TF-RMM’s app_do_extend() appears to calculate:
old_REM[0:hash_size] || new_value[0:size]
where hash_size is 32, 48, or 64 bytes for SHA-256, SHA-384, or SHA-512.
Thus, except when using SHA-512 with size == 64, the hash inputs differ.
The TF-RMM behavior seems closer to the conventional Hash(old
measurement || new contribution) construction used by measurement
registers such as TPM PCRs and Intel TDX RTMRs.
Could you clarify which behavior is intended?
- Is the fixed 1024-bit construction in DEN0137 normative?
- Or should the specification describe the hash-sized/variable-length
construction implemented by TF-RMM?
For context, I have been considering implementing a CCEL replay library
for Arm CCA and noticed this mismatch. The exact construction matters
because otherwise the replayed measurements will differ from the REM
values produced by the RMM.
Thanks,
Kohei
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.15 has an
expected code freeze date of 15/05/2026.
Refer to the release cadence section from TF-A documentation
(https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.15 release preparation tasks are on-going and well progressed.
We want to ensure that planned feature patches for the release are submitted in
good time for the review process to conclude.
As a kind reminder and a matter of sharing CI resources, please launch CI
jobs with care e.g.:
*
For simple platform, docs changes, or one liners, use Allow-CI+1 label (no
need for a full Allow-CI+2 run).
*
For large patch stacks use Allow-CI+2 at top of the patch stack (and if
required few individual Allow+CI+1 labels in the middle of the patch stack).
*
Carefully analyze results and fix the change if required, before launching new
jobs on the same change.
*
If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not
added as a gerrit comment on the patch right away please be patient as under
heavy load CI jobs can be queued and in extreme conditions it can be over an
hour before the Build start notice is issued. Issuing another Allow-CI+1 or
Allow-CI+2 label will just result in an additional job being queued.
Thanks & Regards,
Harrison on behalf of the TF-A team
Hi Folks,
It's first time to raise questions here, not sure it's the right place for discussion on
feature planning and support here. The background is our RHEL distributions like RHEL10
supports 64KB (base) page size for arm64, which isn't supported by upstream TF-RMM yet.
So the question is do we have a plan to support 64KB granule size and the estimated time
for it to happen?
Looking at the latest TF-RMM upstream code, 64KB granule size isn't supported as I can
understand.
- In smc_rmm_config_set(), handler of RMI RMM_CONFIG_SET, the configured granule size should
be RMI_GRANULE_SIZE, which is hardcoded to 4KB like below.
/* The implementation currently supports only the 4 KiB RMI Granule size. */
#define RMI_GRANULE_SIZE RMI_GRANULE_SIZE_4KB
- 'struct granule' represents a granule in TF-RMM, whose length is 16-bits. Bits[0 - 9] are curved
out for the reference count, which isn't sufficient when the granule is taken as stage-2 RTT if
the granule size is 64KB. In this specific case, Bits[0 - 13] are needed for the reference count.
- The translation regimes are sticky to 4KB. For example, option 'XLAT_GRANULARITY_SIZE_SHIFT' only
supports 4KB at present.
if(NOT(XLAT_GRANULARITY_SIZE_SHIFT EQUAL "12"))
message(FATAL_ERROR "Only 4K granularity is supported at the moment")
endif()
Thanks,
Gavin
