Writable in-memory mapping inside enclave for an external file
There is an issue that causes a major problem to support unmodified binaries in GrapheneSGX container.
Many applications take the advantage of mmap to transfer the file operations from write/read to memory access while persisting the changes into the storage. It becomes the blocker issue for us to adopt GSGX.
As the following screenshot displayed that shows GSGX so far doesn't support this usage scenarios because MAP_PRIVATE does not carry writes back to the underlying file.
We found the related code located in, that doesn’t support write mapped data into outside of enclave. The Location which reject the writable file memory mapping The Location of PAL_PROT_WRITE definition
We understand the security implication, but this issue blocks this common function and enforce GSGX user to change their applications at design-level, It maybe not a trivial works for GSGX users also not comply with the purpose of GSGX. so I think it would be great if GSGX is able to the flexibility to allow application to mapping external file as writable. the application should be responsible for the security of their persistent data. Thanks.
This Issue may be related to #232
Thanks for the suggestion. In future work, we'd like to do a secure version of this, but it is non-trivial.
An insecure version is relatively easy, but I hesitate to do it without profuse warnings to the user. I would consider accepting such a patch, though, but it might be best to run this by the larger maintainer team for higher-level consensus before implementing this.
@bigdata-memory Is this issue for allowed files, trusted files or protected files?
- Trusted files cannot be writable by design
- Protected files should already support it (please test)
- Allowed files indeed disallow mmap in untrusted memory and instead always copy the contents into enclave memory (and the file changes happen inside enclave memory and are not reflected in outside untrusted memory)
For allowed files, I think we can allow mmapping to untrusted memory and allow writes. Probably with a manifest option to choose between the old behavior and this new one.
@dimakuv it is for allowed files and yes, a manifest option would be sufficient for users to enable this mode for writable file-back mapping in untrusted memory address space. thanks.