Thanks Kohei for reporting this issue. The TF-RMM implementation is not aligned to the Beta 3 specification and the specification is authoritative on this.

I have pushed a patch to align to the specification. Could you please review this and let us know whether this resolves the issue ?

https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/55708

Best Regards Soby Mathew

From: Kohei Enju via tf-rmm tf-rmm@lists.trustedfirmware.org Date: Tuesday, 20 October 2026 at 14:23 To: tf-rmm@lists.trustedfirmware.org tf-rmm@lists.trustedfirmware.org Subject: [tf-rmm] REM extend behavior: specification vs TF-RMM implementation

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 _______________________________________________ tf-rmm mailing list -- tf-rmm@lists.trustedfirmware.org To unsubscribe send an email to tf-rmm-leave@lists.trustedfirmware.org