Conversation
d4587b9 to
e026aae
Compare
7f4899c to
4249f55
Compare
83b5110 to
66bf651
Compare
|
EDIT: Changed this to match the CLI's opt-in behavior. |
a475695 to
d289cdd
Compare
This adds definitions for the insecure platform variants.
This adds stub reference values for the insecure development platforms to the JSON file with all the reference values.
This adds support for insecure platforms to `contrast generate`. To enable generation for insecure platforms, both the `--INSECURE` flag and the `CONTRAST_ALLOW_INSECURE_RUNTIMES` environment variable need to be set. The `contrast-cc-*` and `contrast-insecure-*` runtimes can be used interchangeably. The bare `contrast-cc` and `contrast-insecure` only resolve if `--reference-values` is set to a CC/insecure platform, respectively.
This adjusts the justfile to include insecure runtimes. Additionally, it makes the `just runtime` target *overwrite* the runtimes instead of appending them. The latter caused issues when the file already had content from a previous run, and I don't see any use for that behaviour.
This adds the node deployment step for the insecure platforms. It uses the same Kata configuration as the CC variants, but strips the CC- enabling values from there.
This adds an insecure attestation issuer / validator implementation. This implementation just forwards the hostdata-provided initdata digest to the validator. The scaffolding necessary for this is optionally making the initdata-processor long-running to expose the initdata digest via an HTTP server, as the configfs-backed hostdata channel is not available on insecure platforms.
This requires the coordinator to be initially configured to allow insecure runtimes by requiring the `CONTRAST_ALLOW_INSECURE` environment variable to be set within the coordinator. This prevents deploying an insecure manifest to a previously-secure runtime, which is a use-case we don't need to support.
This adds the same `--INSECURE` and `CONTRAST_ALLOW_INSECURE_RUNTIMES` toggles to `contrast verify` that are already present in `contrast generate`.
This adds a basic E2E test for the insecure runtimes.
With insecure GPU VMs, we ran into OOM kills on larger VM sizes. The theory is that this is caused by IOMMU page tables which are only allocated when VFIO passthrough is used. In the CC case, these page tables get allocated under the TDX modules' memory. For the non-CC case, they are part of the QEMU process, and thus contribute to the memory usage within the Kubelet's cgroup. To counter this, we add a little bit of extra overhead for insecure GPU VMs.
For verifying an insecure deployment, an SDK user must now instantiate the client `.WithInsecure`, aligning it to the CLI behavior.
d289cdd to
4b54b0e
Compare
burgerdev
left a comment
There was a problem hiding this comment.
Hey @msanft,
Thanks for the PR. I think this could be split up naturally into at least the following intermediate features which don't need to be submitted all at once:
- prefactoring for the
contrast-ccruntime class name matching. - Insecure issuer and verifier, not wired into anything but tested against each other.
- initdata processor
- runtime and nodeinstaller changes
- support for insecure manifests at the Coordinator
- support for insecure manifests at the CLI
- e2e test with insecure
- support for insecure manifests in SDK
That should make review (and iteration) much easier - thanks!
@burgerdev: We'll have to find a good working mode for this. For me, as the PR author, rebasing a stack of N PRs is very tedious. That was my rationale for bundling these changes into a single PR and relying on reviewable commits instead. I'll try to split up into multiple PRs as you suggested. |
|
I split this with the help of AI: --- START AGENT OUTPUT
Each PR is based on the previous one. --- END AGENT OUTPUT |
This adds support for insecure non-CC runtimes. These can be used both for testing in PoC-like settings where Contrast needs to be integrated into a given platform where CC hardware is not yet available, but also eases benchmarking of CC against non-CC performance for Contrast consumers.
This PR only adds the technical implementation for the insecure runtimes, but doesn't yet expose it to the user via release artifacts or documentation.
Despite the PR size, I opted to combine the changes into a single PR with reviewable commits, since -imo- having the full test coverage of all the code makes it easier to reason about the treewide changes. Let me know if you want anything adjusted.
Closes CON-2, CON-3, CON-4