gcs-sidecar: stage amdsnppspapi.dll into CWCOW container security-context dir#2802
gcs-sidecar: stage amdsnppspapi.dll into CWCOW container security-context dir#2802anmaxvl wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR extends the WCOW gcs-sidecar to stage the AMD SNP PSP API DLL (amdsnppspapi.dll) into each confidential container’s security-context directory and updates the container PATH so workloads can LoadLibrary it by name. It also adjusts the security-context directory writer to return the created directory path, enabling additional staging steps.
Changes:
- Update
SecurityOptions.WriteSecurityContextDirto return the created security-context directory path (or empty string if none created). - In the WCOW gcs-sidecar container-create flow, stage
amdsnppspapi.dllfrom the UVM’s System32 into the security-context directory and append that directory toPATH. - Add Windows unit tests covering DLL staging and PATH manipulation behavior.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| pkg/securitypolicy/securitypolicy_options.go | Changes WriteSecurityContextDir to return the created directory path (enables downstream staging). |
| internal/guest/runtime/hcsv2/uvm.go | Updates LCOW call site to handle the new (string, error) return signature. |
| internal/gcs-sidecar/handlers.go | Adds DLL staging into the security-context directory and PATH updates for WCOW workloads. |
| internal/gcs-sidecar/stage_dll_test.go | Adds Windows unit tests for stageDLL and appendToPathEnv. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
anmaxvl
force-pushed
the
amdsnppspapi-in-security-context
branch
from
074769b to
e6b89bb
Compare
| // UVM_SECURITY_CONTEXT_DIR env injection done by WriteSecurityContextDir. | ||
| if securityContextDir != "" { | ||
| if err := stageSnpPspDLL(ctx, &spec, securityContextDir); err != nil { | ||
| return fmt.Errorf("failed to stage %s: %w", amdSnpPspDLLName, err) | ||
| } | ||
| } |
There was a problem hiding this comment.
Untested, but I'm not sure if this will work, we might need to add the environment variables in executeProcess's processParams.Environment (but maybe @takuro-sato is making that processParams.Environment come from a stored OCI spec instead?)
There was a problem hiding this comment.
Adding this env should happen in executeProcess at least for now as env vars are not passed to inbox inbox in createContainer.
After I finish my change it can be in between createContainer enforcement and b.hostState.AddContainer(req.ctx, containerID, c); (, where the enforcement result is stored) too.
Env var enforcement will be like:
- createContaiener enforces and drops env vars and save the result in memory (resulting env vars are not passed to inbox gcs)
- executeProcess gets a request including env vars and check they match the env vars in memory (currently this part is missing)
anmaxvl
force-pushed
the
amdsnppspapi-in-security-context
branch
from
e6b89bb to
a6cbaf8
Compare
micromaomao
left a comment
micromaomao
left a comment
There was a problem hiding this comment.
approach looks good to me (I assume by adding the security context to PATH dlls can be loaded from there when using LoadDLL / NewLazyDLL
…text dir Confidential WCOW workloads need the AMD SNP PSP API DLL (amdsnppspapi.dll) to fetch SNP attestation reports, but it only exists in the UVM's System32 and cannot be bind-mounted as a single file. Copy the DLL from the UVM's System32 into each confidential container's existing security-context directory and append that directory (as seen from inside the container) to the container PATH so it is discoverable via LoadLibrary. Staging happens after security policy enforcement, consistent with the existing UVM_SECURITY_CONTEXT_DIR injection, and is a no-op when the DLL is absent (e.g. non-SNP UVMs). WriteSecurityContextDir now returns the created directory path so the sidecar can stage additional files into it; the Linux GCS call site is updated accordingly. Adds unit tests for stageDLL and appendToPathEnv. Signed-off-by: Maksim An <maksiman@microsoft.com> Assisted-by: Claude Opus 4.8
anmaxvl
force-pushed
the
amdsnppspapi-in-security-context
branch
from
a6cbaf8 to
693c98a
Compare
KenGordon
left a comment
KenGordon
left a comment
There was a problem hiding this comment.
Will discuss the pros and cons of path business today.
| return false, fmt.Errorf("failed to copy %s to %s: %w", srcPath, dstPath, err) | ||
| } | ||
|
|
||
| spec.Process.Env = appendToPathEnv(spec.Process.Env, containerDir) |
There was a problem hiding this comment.
Since any client of the driver will need to be picking up the certs, uvm reference info etc it will need to be explicitly using the security context directory so I think it can also construct the path to the dll. We can add that into the go code in the SKR and the cpp PspUtils tool as examples. Thus I am not certain we should do this path manipulation here. Open to debate I guess.
Confidential WCOW workloads need the AMD SNP PSP API DLL (amdsnppspapi.dll) to fetch SNP attestation reports, but it only exists in the UVM's System32 and cannot be bind-mounted as a single file.
Copy the DLL from the UVM's System32 into each confidential container's existing security-context directory and append that directory (as seen from inside the container) to the container PATH so it is discoverable via LoadLibrary. Staging happens after security policy enforcement, consistent with the existing UVM_SECURITY_CONTEXT_DIR injection, and is a no-op when the DLL is absent (e.g. non-SNP UVMs).
WriteSecurityContextDir now returns the created directory path so the sidecar can stage additional files into it; the Linux GCS call site is updated accordingly. Adds unit tests for stageDLL and appendToPathEnv.
Assisted-by: Claude Opus 4.8