make memory encryption bit an upper limit for physical address bits - #603
Merged
Merged
Conversation
Freax13
force-pushed
the
encryption-bit-limit
branch
from
September 12, 2026 08:57
725b356 to
293cce0
Compare
Member
Author
|
The failing CI jobs will be addressed by #604. |
Freax13
force-pushed
the
encryption-bit-limit
branch
from
September 12, 2026 12:31
293cce0 to
40f5b2f
Compare
Freax13
force-pushed
the
encryption-bit-limit
branch
from
September 12, 2026 12:33
40f5b2f to
aac2dd0
Compare
phil-opp
approved these changes
Sep 15, 2026
phil-opp
left a comment
Member
There was a problem hiding this comment.
Looks good overall, thanks a lot! I would update the safety docs in two places, but otherwise this looks ready to be merged.
Comment on lines
579
to
581
Member
There was a problem hiding this comment.
We should document here that no bits above the encryption bit must be set if memory encryption is enabled.
|
|
||
| let c_bit_mask = 1u64 << bit_position; | ||
| let addr_mask = u64::MAX << bit_position; | ||
| PHYSICAL_ADDRESS_MASK.fetch_and(!addr_mask, Ordering::Relaxed); |
Member
There was a problem hiding this comment.
This assumes that the method is only called once, right? We should add that to the safety docs of the method?
Member
Author
There was a problem hiding this comment.
Yes. I update the doc comment.
Ensure that no bit above the C-bit/S-bit is set: - TDX already requires this: "GPA bits higher than the SHARED bit are considered reserved and must be 0. Address translation with any of the reserved bits set to 1 cause a #PF with PFEC (Page Fault Error Code) RSVD bit set." (Architecture Specification: Intel® Trust Domain Extensions (Intel® TDX) Module, 13.11.1. GPAW-Relate EPT Violations). - AMD CPUs don't have the same restriction, however in practice, the C-bit is always the upmost supported physical adddress bit. Client parts and server parts up until Rome support 48 physical address bits and use bit 47 as the C-bit. Server parts starting with Milan support 52 physical address bits and always use bit 51 as the C-bit. Thinking about this, this makes sense: If the CPU allowed bits higher than the C-bit to be used for address bits, this would fragment the physical address space and make large parts of it effectively unusable.
Freax13
force-pushed
the
encryption-bit-limit
branch
from
September 16, 2026 12:21
aac2dd0 to
73ebafc
Compare
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
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.
Ensure that no bit above the C-bit/S-bit is set: