Am Freitag, 24 Juni 2016, 08:33:24 schrieb Balbir Singh:
On 24/06/16 02:44, Thiago Jung Bauermann wrote:
quoted
Sorry, I still don't understand your concern. What kind of cheating?
Which values? If it's the values in the event log, there's no need to
trust the old kernel. The new kernel knows that the old kernel didn't
pass wrong measurement values in the event log because it can
recalculate the PCR extend operations recorded in the log and compare
the results of the replay with the current PCR values stored in the TPM
device. If they match, then the event log is guaranteed to be correct.
If they don't match, either the memory was corrupted somehow during the
kexec process, or the old kernel tried to pass a falsified event log.
Yep, get it/got it. My concern was anything using passed on the values
should compare the results with the current PCR values.
BTW, what do we gain by passing the values if we are relying on the PCR
registers anyway, can't we directly read them off from there? Aren't we
going to ready anyway to compare, what does passing the values gain?
The PCR values themselves change for reasons that the application/user may
not care about. For example, just changing the order in which measurements
are made changes the final value of the PCR, even if all the measurements
themselves don't change. And in current multi-processor machines this order
does change at each boot, so you can't rely on two boots of the same machine
with the same software to have the same PCR values.
Also, you may want to verify only the measurement of one of the components
and not care about the other components.
With an event log, you can verify the checksum of each measured component
individually, and the PCR value serves to confirm that the event log is
correct. Just having the final PCR value without the event log, you don't
know which measurements were made.
quoted
quoted
and
How do we know the new kernel is safe to load - I guess via a signature
that the new kernel is signed with (assuming it is present in the key
ring).
Correct. That goal is met by signature verification, not by integrity
assurance.
I'll note that even with both of my patch series there's still code
missing for kernel signature verification in PowerPC. I believe there's
not a file format defined yet for how to store a signature in a PowerPC
kernel image.
Integrity assurance doesn't depend on kernel signature verification
though. There's value in both my patch series even without kernel
signature verification support. They're complementary features.
Thanks for clarifying
Thank you for your interest.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center