Set HCSSHIM_UVM_REFERENCE_INFO env for workload containers

[anmaxvl]

Workload containers need to be aware of the reference UVM measurement
they are currently running on. The expectation is that the signed UVM
measurement file will be a part of the package and located in the
same directory as the rest of the boot files (e.g. kernel, initrd
or VMGS). The file itself is a COSE_Sign1 document containing the
measurement and related information.
The content of the file will be plumbed to the UVM as
part of setting the security policy request and can later be
presented to the containers via an environment variable.

Signed-off-by: Maksim An maksiman@microsoft.com

[KenGordon]

My main point is to be careful of the naming. Especially that what we are conveying is an expected, allowed or reference measurement rather than an actual measurement of the currently running UVM. The information is signed and while it must at least contain the measurement it also contains other information such as a SVN.

[helsaawy]

Just to verify, it is the workload container's job (and not the pod/gcs) to validate the measurement/signature, right?

[anmaxvl]

Just to verify, it is the workload container's job (and not the pod/gcs) to validate the measurement/signature, right?

correct.

[KenGordon]

Just to verify, it is the workload container's job (and not the pod/gcs) to validate the measurement/signature, right?

correct.

I may seem pendantic but no, it MUST be verified off the box or an evil UVM can attach a container such that it passes the test and then cover up. Whether that call to "off the box" is set off by the gcs or a container (infra or payload) doesn't matter to the security properties but happens to be done by containers. So far there are two models - 1) MAA checks as part of some key release scheme 2) CCF where new nodes on the network provide attestation etc to the existing nodes who then check it and decide to allow the new node in or not.

This might be thought of as not marking your own homework.

[helsaawy]

Whether that call to "off the box" is set off by the gcs or a container (infra or payload) doesn't matter to the security properties but happens to be done by containers.

So we could have the GCS verify the signature, but just decided against it?
I was wondering why I didn't see any code to verify the signature, so my worry was that this PR was incomplete/missing key functionality.

[anmaxvl]

Whether that call to "off the box" is set off by the gcs or a container (infra or payload) doesn't matter to the security properties but happens to be done by containers.

So we could have the GCS verify the signature, but just decided against it? I was wondering why I didn't see any code to verify the signature, so my worry was that this PR was incomplete/missing key functionality.

Ken can correct me here, but in the context of THIS PR there's no expectation for the GCS or UVM validating the measurement/signatures and whatever needs to happen for that, will happen inside a container (that includes the "off the box" call). I'm not sure about the CCF and "new nodes" use case, but the new environment variable will most likely be used for things like MAA.

[KenGordon]

Whether that call to "off the box" is set off by the gcs or a container (infra or payload) doesn't matter to the security properties but happens to be done by containers.

So we could have the GCS verify the signature, but just decided against it? I was wondering why I didn't see any code to verify the signature, so my worry was that this PR was incomplete/missing key functionality.

GCS cannot check the measurement of the UVM as an "evil" UVM might change that test to always pass. However, GCS could ask another service (eg MAA) to check the measurement but we have decided not to do that and leave it to the customer containers to implement that checking (eg via MAA) as it allows flexibility in how that is done (eg CCF and Stavros' SKR do it entirely differently).

Thus, we are only passing the COSE_Sign1 document through via hcsshim, gcs and the local payload container to the ultimate verifier.