Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About root_page_table_storage #471

Open
alan2031 opened this issue Sep 26, 2024 · 2 comments
Open

About root_page_table_storage #471

alan2031 opened this issue Sep 26, 2024 · 2 comments

Comments

@alan2031
Copy link

Hello, may I ask where the root page table of the eapp is assigned? In /runtime/loader.S, the value of root_page_table_storage is written to satp, but there is no file that assigns a value to root_page_table_storage.

@grg-haas
Copy link
Collaborator

Hi @alan2031! root_page_table_storage is a statically allocated array that is initially empty. It is filled out (via a pointer named root_page_table) as the eapp's virtual memory is initialized

@alan2031
Copy link
Author

Hi @alan2031! root_page_table_storage is a statically allocated array that is initially empty. It is filled out (via a pointer named root_page_table) as the eapp's virtual memory is initialized

Hi grg-haas! Thank you for your response!I have another question: My understanding is that when the runtime ELF loader loads the eapp, it traverses the second-level and third-level page tables and establishes the address mappings. At this time, the second-level and third-level page tables reside in the enclave's free memory (freemem), where they are protected. However, when allocating the root_page_table_storage region, its specific physical memory address is not explicitly specified. So how is the root page table protected?

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

No branches or pull requests

2 participants