On 9/1/2023 5:22 PM, Tushar Sugandhi wrote:
On 8/30/23 12:12, Ken Goldman wrote:
On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
For remote attestation to work, the service will need to know how to
validate the snapshot_aggregate entry in the IMA log. It will have
to read the PCR values present in the template data of
snapshot_aggregate event in the latest IMA log, and ensure that the
PCR quotes align with the contents of the past UM_snapshot_file(s).
This will re-establish the chain of trust needed for the device to
pass remote attestation. This will also maintain the ability of the
remote-attestation-service to seal the secrets, if the client-server
use TPM unseal mechanism to attest the state of the device.
I think that seal/unseal to IMA PCRs is futile. Since boot is
multi-threaded, the IMA PCR is unpredictable even when valid.
True. But here we are talking about seal/unseal post boot when the
device is in a stable state, and there are relatively less number of
events extending IMA PCR. The value of the actual IMA PCR doesn't matter
in this context as long as it stays the same between seal-unseal window.
Does 'relatively less number of events' really matter? Even if there
are only two, if the order is unpredictable, unseal fails.
If it changes between that window, the clients typically retry by
sending the request to the service with a new stable PCR.
Does a retry help? Once the PCR has been extended to the wrong value, it
can never get back to the correct value without a reboot.
Seal-unseal is supported by TPM spec, and is used widely. So we had to
ensure that our proposed design wouldn't regress this existing
functionality.
It works in the pre-OS environment, where the firmware specification
mandates that the PCR values are repeatable. Once you're post-OS,
multi-threaded, an unseal that includes PCR 10 is infeasible.
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
