intel / intel/confidential-computing.tdx.tdx-module

TDG.MEM.PAGE.ACCEPT fails on a GPA whose SEPT entry is in the REMOVED state

Open
#18 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
113
Forks
24
PR merge metrics
No merged PRs in 30d

Description

I'm unsure if this is a TDX module bug, and if it isn't, I would appreciate any insights on the issue I am seeing.

## Issue Description

When there's a private→shared memory conversion (on a migration source) during live migration of a TD using private pages that were already exported, we execute the `TDH.EXPORT.MEM(CANCEL)` operation on the associated GFN. The related SEPT entry on the destination is then transitioned to the REMOVED state (rather than FREE) during `TDH.IMPORT.MEM`. This appears to work correctly.

However, after migration is complete and the migrated destination TD is running, when it attempts to convert that shared GFN back to private, `TDG.MEM.PAGE.ACCEPT` fails with `0xC0000B0B00000001` (TDX_PAGE_SIZE_MISMATCH), thereby preventing a private page from being mapped at that address.

For clarity, consider the loading/unloading of a driver inside the guest as the trigger for these private↔shared conversions.

## Analysis

Since these conversions work without issue on a running TD (i.e., outside of the migration scenario), I was wondering if there's something about the SEPT entry being in the REMOVED state that causes this failure.

https://github.com/intel/tdx-module/blob/b6b30937ea5edef8bf656615fd7869bcddd320bd/src/td_dispatcher/vm_exits/tdg_mem_page_accept.c#L99-L107

## Questions

1. Could the issue be that the validation logic above only checks if the SEPT entry is in the FREE state and does not include the REMOVED state? If the SEPT entry remains in the REMOVED state after migration, this could explain the PAGE_SIZE_MISMATCH error based on the logic in the snippet above.

2. Is `TDG.MEM.PAGE.ACCEPT` expected to handle SEPT entries in the REMOVED state?

3. Are there any other considerations regarding MMU flows or interactions with the TDX ABI during the initial private→shared conversion in the in-order migration phase on the source that could explain the behavior I'm seeing?

Contributor guide

Open the contributing guide

Research direction

Start with src/td_dispatcher/vm_exits/tdg_mem_page_accept.c at the linked validation logic, then trace the described TDH.EXPORT.MEM(CANCEL) and TDH.IMPORT.MEM migration flow. Determine whether a REMOVED SEPT entry is expected to be accepted and identify the TDX ABI or MMU behavior that explains the PAGE_SIZE_MISMATCH result; completion requires a documented root cause and resolution.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
operating-systems, security
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.