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