Skip to content

make memory encryption bit an upper limit for physical address bits - #603

Merged
Freax13 merged 1 commit into
rust-osdev:nextfrom
Freax13:encryption-bit-limit
Sep 16, 2026
Merged

Freax13 merged 1 commit into
rust-osdev:nextfrom
Freax13:encryption-bit-limit

Conversation

@Freax13

@Freax13 Freax13 commented Sep 12, 2026

Copy link
Copy Markdown
Member

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 Freax13 changed the title make memory encryption bit an upper limit make memory encryption bit an upper limit for physical address bits Sep 12, 2026
@Freax13
Freax13 force-pushed the encryption-bit-limit branch from 725b356 to 293cce0 Compare September 12, 2026 08:57
@Freax13

Freax13 commented Sep 12, 2026

Copy link
Copy Markdown
Member Author

The failing CI jobs will be addressed by #604.

@Freax13
Freax13 force-pushed the encryption-bit-limit branch from 293cce0 to 40f5b2f Compare September 12, 2026 12:31
@Freax13 Freax13 mentioned this pull request Sep 12, 2026
@Freax13
Freax13 force-pushed the encryption-bit-limit branch from 40f5b2f to aac2dd0 Compare September 12, 2026 12:33

@phil-opp phil-opp left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good overall, thanks a lot! I would update the safety docs in two places, but otherwise this looks ready to be merged.

Comment thread src/addr.rs Outdated
Comment on lines 579 to 581

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should document here that no bits above the encryption bit must be set if memory encryption is enabled.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Done


let c_bit_mask = 1u64 << bit_position;
let addr_mask = u64::MAX << bit_position;
PHYSICAL_ADDRESS_MASK.fetch_and(!addr_mask, Ordering::Relaxed);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This assumes that the method is only called once, right? We should add that to the safety docs of the method?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

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
Freax13 force-pushed the encryption-bit-limit branch from aac2dd0 to 73ebafc Compare September 16, 2026 12:21
@Freax13
Freax13 merged commit 78b8102 into rust-osdev:next Sep 16, 2026
11 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants