Skip to content

Conversation

tjones60
Copy link
Contributor

When strict encryption policy is not enabled, allow the HCL to GspById if GspKey is not available.

@tjones60 tjones60 requested a review from a team as a code owner September 30, 2025 23:27
@Copilot Copilot AI review requested due to automatic review settings September 30, 2025 23:27
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR modifies the guest state encryption policy behavior to allow fallback from GspKey to GspById when strict encryption policy is not enabled. The change enables more flexible encryption handling while maintaining security requirements when strict policy is active.

  • Updates GspKey policy documentation to reflect fallback behavior
  • Modifies encryption requirement logic to consider strict policy setting
  • Adjusts logging and warning conditions for policy mismatches

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File Description
vm/devices/get/get_protocol/src/dps_json.rs Updates documentation for GspKey enum variant to describe fallback behavior
openhcl/underhill_attestation/src/lib.rs Implements fallback logic from GspKey to GspById when strict encryption is disabled

Comment on lines +681 to +684
|| (matches!(
guest_state_encryption_policy,
GuestStateEncryptionPolicy::GspKey
);
) && strict_encryption_policy);
Copy link
Preview

Copilot AI Sep 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] The parentheses around the matches! expression create unnecessary complexity. The logical precedence already ensures correct evaluation without the extra parentheses.

Copilot uses AI. Check for mistakes.

Comment on lines 890 to 892
if !matches!(
guest_state_encryption_policy,
GuestStateEncryptionPolicy::None
GuestStateEncryptionPolicy::GspById | GuestStateEncryptionPolicy::Auto
Copy link
Preview

Copilot AI Sep 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] The logic has been inverted with !matches! which makes it harder to follow. Consider using positive logic by matching the policies that should trigger the warning: GuestStateEncryptionPolicy::None | GuestStateEncryptionPolicy::GspKey.

Copilot uses AI. Check for mistakes.

Comment on lines 1038 to 1040
if !matches!(
guest_state_encryption_policy,
GuestStateEncryptionPolicy::None | GuestStateEncryptionPolicy::GspById
GuestStateEncryptionPolicy::GspKey | GuestStateEncryptionPolicy::Auto
Copy link
Preview

Copilot AI Sep 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] Similar to the previous comment, the inverted logic with !matches! reduces readability. Consider using positive matching for the policies that should trigger this condition: GuestStateEncryptionPolicy::None | GuestStateEncryptionPolicy::GspById.

Copilot uses AI. Check for mistakes.

@tjones60 tjones60 added the backport_2505 Change should be backported to the release/2505 branch label Sep 30, 2025
stunes-ms
stunes-ms previously approved these changes Oct 1, 2025
@chris-oo
Copy link
Member

chris-oo commented Oct 1, 2025

tbh copilot's feedback is pretty valid here, the !matches is a bit weird.

@tjones60
Copy link
Contributor Author

tjones60 commented Oct 3, 2025

tbh copilot's feedback is pretty valid here, the !matches is a bit weird.

It might look weird, but it makes more sense to me: Here I want: If we are not using the encryption method that was requested, log this warning. The positive version is less clear, and could become incorrect in the future if different encryption policies are added (Hardware sealing?)

@tjones60
Copy link
Contributor Author

tjones60 commented Oct 8, 2025

tbh copilot's feedback is pretty valid here, the !matches is a bit weird.

I realized I can just swap the if order.

@tjones60 tjones60 merged commit 03c2edb into microsoft:main Oct 8, 2025
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport_2505 Change should be backported to the release/2505 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants