cvm guest vsm: protections applied to overlay pages shouldn't affect bitmaps #1557
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sluck-msft
added
the
backport_2505
sluck-msft
force-pushed
the
gvsm/fix-overlay-vtl-prot
branch
from
1b3dfe9 to
059bace
Compare
smalis-msft
reviewed
Jun 20, 2025
smalis-msft
reviewed
Jun 20, 2025
| if vtl == GuestVtl::Vtl0 { | ||
| // Only VTL 0 vtl permissions are explicitly tracked | ||
| if calling_vtl == Vtl::Vtl1 && target_vtl == GuestVtl::Vtl0 { | ||
| // Only VTL 1 permissions imposed on VTL 0 are explicitly tracked | ||
| self.vtl0.update_permission_bitmaps(range, protections); |
There was a problem hiding this comment.
It looks like we call update_permission_bitmaps in one other spot below, does it need a similar guard?
There was a problem hiding this comment.
That's the one in change_host_visibility? I think we want to remove the permissions there because it's the encrypted mapping and needs to reflect the underlying partition-wide mapping, I can add a comment.
smalis-msft
reviewed
Jun 20, 2025
| .expect("should be able to apply default protections"); | ||
| self.apply_protections( | ||
| range, | ||
| if self.vtl1_protections_enabled() { |
There was a problem hiding this comment.
This feels odd. I feel like this should be another caller_vtl being passed in, no?
There was a problem hiding this comment.
My thinking is this:
- For change_host_visibility, the calling VTL is itself the "target" vtl (although that doesn't make much sense for host visibility since it applies partition-wide). This is different from modify_vtl_protection_mask, where it should only be a higher VTL targeting a lower VTL.
- When changing from shared to private, we apply the default protections on the page. Either there's a VTL 1 that configured default protections, and therefore we're applying the protections on behalf of VTL 1, or there's no VTL 1 (or it hasn't yet configured default protections) and we're applying the protections on behalf of VTL 2.
smalis-msft
approved these changes
Jun 20, 2025
sluck-msft
added a commit
to sluck-msft/openvmm
that referenced
this pull request
Jun 20, 2025
…bitmaps (microsoft#1557) The bitmaps track VTL 1 protections on VTL 0, and the permissions applied to the overlay pages are imposed by VTL 2. So applying protections to overlay pages, either on registration or deregistration, shouldn't change the bitmaps. Tested: SNP +/- guest vsm
|
Backported in #1567 |
benhillis
added
backported_2505
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The bitmaps track VTL 1 protections on VTL 0, and the permissions applied to the overlay pages are imposed by VTL 2. So applying protections to overlay pages, either on registration or deregistration, shouldn't change the bitmaps.
Tested:
SNP +/- guest vsm