I have some questions to make it clear about how protected file system library works.
Sadly, right now, SGX SDK for Linux does not support protected file system library, hence I cannot see the internal implementation of trusted file system library. so here I ask some details about the library.
Questions are as follow:
1. After creating a SGX_FILE pointer via sgx_fopen(), we write or read data through the pointer. PDF in [here] explains that there exists an OCALL for sgx_fopen(), but no mentions about sgx_fwrite() or sgx_fread(). Do they also have OCALLs for secure file operation? If not, how does it work?
2. Linux has virtual files, like /dev/mem or /dev/shm. I want to make a shared memory region between two enclaves (not belongs to the same process) via sgx_fopen("/dev/shm") with the session key created by DHKE library. Is it possible to open a virtual file with sgx_fopen()?
As of now Protected file system library is available for Windows SGX Applications only.
1) Yes there is an OCALL for sgx_fopen() from the Protected FS trusted Library to the the Protected FS untrusted Library which is Linked to the hard disk containing the files as shown in the figure of the document . We can find these OCALL's in the edl file (INTELSGXSDK\include\sgx_tprotected_fs.edl) of the protected FS library. Yes there exists an OCALL for the sgx_fread and sgx_fwrite in the edl file. Please check the edl file for more reference.
Regarding your second question, the answer is no.
The protected FS is designed to work with real files. it includes meta-data so it can only be accessed by one process at a time if opened for writing (one writer or many readers).
Protected FS is designed for saving enclave persistent data, not as a comunication channel between enclaves.
Arya Pourtabatabaie wrote:
Are the two enclaves you are talking about hosted by the same untrusted app?
No. The example of local attestation already provides how to communicate between two enclaves hosted by the same untrusted app. The two enclaves that I said belong to different untrusted apps.
Can you perhaps pipe data between the two processes?
If so, you can simply use some variation of AES in counter mode and then communicate the data through the untrusted host apps.