For the extend runtime measurement op we currently have 2 defaults, one hardcoded and one specified in the configuration file.
Only the initial extend operation will use the PCR in the config, if called via an API (w/o specifying a concrete register) the extend op will default to the hardcoded instead of the value specified in the config file.
This behaviour implies that the caller of the RPC method has knowledge about the internals of the TEE (valid PCR registers), which is unfortunate (would need a kata-agent config, for example)
This PR consolidates the algo to pick a PCR for all extend ops:
1) PCR specified in the call
2) PCR specified in config file
3) Hardcoded default PCR
For the extend runtime measurement op we currently have 2 defaults, one hardcoded and one specified in the configuration file.
Only the initial extend operation will use the PCR in the config, if called via an API (w/o specifying a concrete register) the extend op will default to the hardcoded instead of the value specified in the config file.
This behaviour implies that the caller of the RPC method has knowledge about the internals of the TEE (valid PCR registers), which is unfortunate (would need a kata-agent config, for example)
This PR consolidates the algo to pick a PCR for all extend ops: 1) PCR specified in the call 2) PCR specified in config file 3) Hardcoded default PCR
Drive-by fix: Cargo.lock update