-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set HCSSHIM_UVM_REFERENCE_INFO env for workload containers #1499
Conversation
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to verify, it is the workload container's job (and not the pod/gcs) to validate the measurement/signature, right?
correct. |
26f9a39
to
2a61ca5
Compare
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. |
So we could have the GCS verify the signature, but just decided against it? |
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. |
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>
Signed-off-by: Maksim An <maksiman@microsoft.com>
2a61ca5
to
d7c6afd
Compare
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. |
…#1499) * Set HCSSHIM_UVM_REFERENCE_INFO env for workload containers 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>
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