@mssun As we discussed, It is quite challenging to maintain the security model for this integration because the GSGX is not designed to be integrated in API level, it has to be running in external processes, the secrets and encrypted workload/inputs/arguments are required to be exchanged with a new pre-load module which, in turns, needs to do the following tasks:
1) mutual attesting with Teaclave executor 2) establish a trusted channel with Teaclave executor 3) receive and parse the workload binaries and dependencies, input files, arguments, those are all complex objects. 4) deploy received workload binaries and dependencies, input files, arguments to GSGX enclave at runtime in correct layout and aligned with pre-defined GSGX manifest 5) the output of GSGX needs to be serialized and send back to Teaclave executor. 6) The pre-load module cannot manage the lifecycle of workload that is running in GSGX due to the limitation of GSGX, it has to be handled by Teaclave executor in external Linux signal mechanism, but it is not reliable and GSGX doesn't honor some signal type and still unstable to handle basic signals in GSGX In addition, The GSGX is limited to run unique workload, it means it doesn't natively support measurement decoupling feature (refused by GSGX maintainer ITL), it implies a huge performance penalties and significant SGX resource consumption for FaaS usage scenario. -- 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-920158704
