I'm also interested in incorporating Graphene as an Executor of Teaclave. However, I think we must take serious consideration about the interfaces of Graphene (mainly system calls).
As @bigdata-memory mentioned, many syscalls are handled by libOS, but there're also many syscalls which are forwarded, either in unaltered way or with some changes, to the OS kernel. These forwarded syscalls includes I/O operations on file system, Networks, as well as timing system (e.g. `nanosleep`) and synchronization (e.g. `futex`). Besides, Graphene can also handle interrupts/exceptions. To avoid using such untrusted interfaces and information leakage on these interfaces, Teaclave implements *no* untrusted interface. And Graphene aims to support *trusted binary*, whereas Teaclave assumes *potentially malicious function*. Such difference in threat model results in the differences on supported/exposed interfaces to binaries/functions running inside Graphene/Teaclave. If we want to leverage Graphene's power, we may need to think about several questions: - Tradeoff between binary compatibility and security: how to deal with untrusted interfaces? - How to run `untrusted binary` in Graphene securely? Personaly I believe auditing can be a solution - How can Teaclave and Graphene communicate securely? AFAIK, Graphene currently lacks a secure channel implementation. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/525#issuecomment-884412237
