search

DMTF / libspdm

BSD 3-Clause "New" or "Revised" License
116 stars 106 forks source link

Whether measurement block format is included or not in the calculation of measurementSummaryHash #2888

Closed rioone2023 closed 3 weeks ago

rioone2023 commented 3 weeks ago

The result of discussions in https://github.com/DMTF/libspdm/issues/2404 is to include the measurement block format byte offset [0-3] in the measurementSummaryHash calculation for all SPDM versions.

On the other hand, the definition in SPDM v1.1.2 and later is as follows.

hash(Concatenation(MeasurementBlock[0],. MeasurementBlock[1], ...)) where MeasurementBlock[x] denotes a measurement of an element in the TCB.

Here, "measurement" was interpreted as the same as "Measurement block"? When it is simply expressed as "measurement", it can be interpreted as the FW hash value itself, so I think there is an interpretation that does not include the byte offset [0-3] in the Measurement block format. I could not find a clear reason for interpreting "measurement=Measurement block.

steven-bellock commented 3 weeks ago

To me it's clear that MeasurementBlock contains (Index, MeasurementSpecification, MeasurementSize, Measurement) and that is what is concatenated. But I agree the normative text for MeasurementSummaryHash could be made less verbose and more clear.

As an aside, the SPDM Working Group changed the normative text in SPDM 1.1.2 from Measurement to MeasurementBlock because they deemed it a security issue. Otherwise they should have waited until SPDM 1.2 to introduce such a change.

jyao1 commented 3 weeks ago

Yes, it is MeasurementBlock - whole block.

rioone2023 commented 3 weeks ago

Thank you. I had to check the reason of libspdm's implementation because the specification has changed in minor Version(1.1.2) and I thought there is some ambiguity in the description of SPDM v1.1.2 and later. I understand the reason for the change as well.