- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Intel SGX Team,
I wonder if there is a way to read the ciphertext written in the PRM without using special hardware. On page 33 of this ISCA 2015 tutorial link (https://software.intel.com/sites/default/files/332680-002.pdf), it is written that external memory reads and bus snoops can see encrypted data. I found a paper, MEMBUSTER, which does bus snooping by using a signal analyzer (https://www.usenix.org/system/files/sec20summer_lee-dayeol_prepub.pdf).
However, what I just want to do is reading ciphertext written in the PRM. If I make a program as pre-release mode and ptrace the memory, I can only see the decrypted data.
If there is a way to read the ciphertext written in the PRM, please let me know.
Thank you in advance.
Best regards,
David Cho.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good morning David, I hope this note finds your week going well.
I'm not the SGX team but hopefully I can provide some useful illumination on the issue that you raised. Based on the description in your post I'm assuming that you are questioning whether or not it is possible to use a non-SGX enabled application to read the contents of the Processor Reserved Memory (PRM) aperture.
If this is a correct assessment of your question I don't believe the hardware will allow you to do what you are suggesting. The following paper that I authored provides an expanded discussion of the issues that are involved with that, although the paper formally focuses on the impact of speculation vulnerabilities on SGX confidentiality guarantees.
The problem you will face is that PRM is reserved exclusively for access by the processor. That memory aperture is defined by the BIOS/firmware through the Processor Reserved Memory Range Registers (PRMRR's). That memory is then marked by the firmware as reserved in the E820 memory map. So I don't believe that either Linux or Windows will even map that physical memory.
The PRM is divided into two sections referred to as Enclave Page Cache (EPC) and Enclave Page Cache Metadata (EPCM). The only entity that can access the PRM at large is microcode running on the processor. The Page Miss Handler (PMH) fields a request for a page of memory that was configured as part of the enclave loading and initialization process. The PMH is implemented in processor microcode and thus has access to the PRM.
The PMH validates though the EPCM that the request for memory belongs to an enclave that elicited the page fault that resulted in invocation of the PMH. If the access is validated, the PMH populates an entry in the Translation Lookaside Buffer that implements a virtual->physical memory mapping that is needed for the code running in enclave mode to access the physical page of memory in the PRM region.
Any other method of accessing the physical page will be rejected by the memory management unit, since what you are proposing would be a rather serious impairment of the SGX security model as it would allow brute force attacks against the encrypted pages.
The virtual->physical memory reference process is facilitated by the Memory Encryption Engine (MEE) that is one of the hardware components of the SGX security model. The MEE handles encryption/decryption of the data along with the Merkle Tree integrity protections and tag based replay avoidance mechanisms.
Hopefully the above is a helpful summary of the issues involved, Intel engineering may want to provide additional embellishments.
Have a good day.
Dr. Greg
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good morning David, I hope this note finds your week going well.
I'm not the SGX team but hopefully I can provide some useful illumination on the issue that you raised. Based on the description in your post I'm assuming that you are questioning whether or not it is possible to use a non-SGX enabled application to read the contents of the Processor Reserved Memory (PRM) aperture.
If this is a correct assessment of your question I don't believe the hardware will allow you to do what you are suggesting. The following paper that I authored provides an expanded discussion of the issues that are involved with that, although the paper formally focuses on the impact of speculation vulnerabilities on SGX confidentiality guarantees.
The problem you will face is that PRM is reserved exclusively for access by the processor. That memory aperture is defined by the BIOS/firmware through the Processor Reserved Memory Range Registers (PRMRR's). That memory is then marked by the firmware as reserved in the E820 memory map. So I don't believe that either Linux or Windows will even map that physical memory.
The PRM is divided into two sections referred to as Enclave Page Cache (EPC) and Enclave Page Cache Metadata (EPCM). The only entity that can access the PRM at large is microcode running on the processor. The Page Miss Handler (PMH) fields a request for a page of memory that was configured as part of the enclave loading and initialization process. The PMH is implemented in processor microcode and thus has access to the PRM.
The PMH validates though the EPCM that the request for memory belongs to an enclave that elicited the page fault that resulted in invocation of the PMH. If the access is validated, the PMH populates an entry in the Translation Lookaside Buffer that implements a virtual->physical memory mapping that is needed for the code running in enclave mode to access the physical page of memory in the PRM region.
Any other method of accessing the physical page will be rejected by the memory management unit, since what you are proposing would be a rather serious impairment of the SGX security model as it would allow brute force attacks against the encrypted pages.
The virtual->physical memory reference process is facilitated by the Memory Encryption Engine (MEE) that is one of the hardware components of the SGX security model. The MEE handles encryption/decryption of the data along with the Merkle Tree integrity protections and tag based replay avoidance mechanisms.
Hopefully the above is a helpful summary of the issues involved, Intel engineering may want to provide additional embellishments.
Have a good day.
Dr. Greg
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page