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