Description
We've already discussed this in a few places, but this is a detailed issue to capture how we can send the plaintext initdata from the guest to Trustee.
First, we'll need to change the API of the AA so that it can receive the plaintext initdata rather than the hash. See confidential-containers/guest-components#1002
Of course we'll need to adjust Kata to call this API and change how the CAA handles validating the init-data measurement, which is currently not supported on all platforms.
The AA will need to store the initdata somewhere so that it can be used with requests. I'm not yet sure the best place to do this yet. Interestingly we actually instantiate our attesters twice. Once in the AA lib.rs and once in the kbs-protocol.
Next we'll need to change the KBS protocol and add a field for the plaintext initdata. SInce this is potentially large, we probably want a config option in the AA that will control whether the plaintext initdata is used or not.
In the KBS things are relatively simple. We just need to pull the init-data out of the protocol and provide it to the AA, similarly to how we handle the runtime data.
I don't think we'll need any changes in the AS. Once we give the AS the "structured" init-data, it should end up in the attestation token which is supplied to the KBS policy engine allowing users to write policies that check the initdata.
We should probably also support this in the kbs-client so that we can have an init-data integration test and so that people can use it with VM workloads.