Import third-party Lua libs usable in LuaSGX

[Lorel]

Particularly, we'd like to use LuaCSV(C library) inside an enclave

[Lorel]

LuaCSV has been imported in LuaSGX by rafael It can be called from the global variable ccsv So we can use this workaround for Debs (-> I remove the issue from the milestone) But for future usage, we need a mechanism to import third-party libraries

[rafaelppires]

It is not possible to dynamically add machine code to enclaves after they were created. Only by statically linking the additional code into the signed shared library that is loaded as enclave.

[Lorel]

@rafaelppires you're able to do it, you just have done it, so it is possible could you do a doc on how you added LuaCSV to LuaSGX? it would be a good start

anyway:

[rafaelppires]

I thought you meant by 'import' the usual '.so' way of doing it.

[Lorel]

I know that we cannot import a lib into an enclave on-the-fly But we can automatize the build process of LuaSGX inside a Docker image That's why I'd need a doc about how you process that

[rafaelppires]

It is rather manual. It depends on the code. For the cjson I did a static library and linked it to the enclave. The csv was simpler, so I just added it as source file. Each approach requires a different manipulation of the Makefile. The enclave code also changes to add the initialization call for the new packages.

[Lorel]

so I wait for your documentation about that to see how we can deal with that but like I said, there is not any hurry for that

[vschiavoni]

Yes, no hurry :-)

On Sun, 26 Feb 2017 at 18:21, Aurelien HAVET notifications@github.com wrote:

so I wait for your documentation about that to see how we can deal with that but like I said, there is not any hurry for that

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Lorel/0MQRxLua-MFR-POC/issues/4#issuecomment-282571325, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHRqAawcU8aG6JT8RsAP0CqvlDwKSQVks5rgbSogaJpZM4MMHWR .

--

Valerio

[rafaelppires]

rafaelpp [5:51 PM] (...) like I said in the github: it depends. What I did for cjson was different from csv, because of their sizes. Each package can have its particularities and, in fact, it is not a good idea for security.

aurelien [5:53 PM] Can you explain me how you processed for these two cases in a documentation, and why it is a bad idea for security in the same document ?

rafaelpp [5:53 PM] not now or in the following days but yes

aurelien [5:55 PM] As soon as you can, it is not needed for our next target, but we should seriously think about this approach for later, in case if we go further

rafaelpp [6:04 PM] I see. The security reason is basically because you should put the fewer possible inside enclaves. If you allow anything, you increase your trusted computing base, and the area of attack. The extreme is when the assurance given by SGX becomes useless (if someone puts malware inside your lua package or even bad code - sth that allows buffer overflows or uses forbidden instructions inside enclaves, for instance). That is the same reason one should not allow arbitrary amounts of data to enter the enclave at a given time and having a limit is better (like the one of 8K) for security reasons. There is a tradeoff between flexibility and security, and SGX is about security

aurelien [6:14 PM] so here you think we should abort securestreams because it doesn't comply with SGX by design :thinking_face:

rafaelpp [6:15 PM] not at all but the less inside, the better

aurelien [6:17 PM] but you understand that we can not propose a dataflow programming framework where some processes are executed inside SGX enclaves with so many restrictions ?

rafaelpp [6:17 PM] that's the price you pay for having security: the restrictions

aurelien [6:18 PM] please, just give me the recipes you used for include these two libraries, and let think together what we can do in the future, ok?

rafaelpp [6:19 PM] sure