How the direct syscalls are handled? about graphene HOT 7 CLOSED

Hi,

System calls made from the binaries are restricted by the SECCOMP filter (described in our original paper: http://www.oscar.cs.stonybrook.edu/papers/files/tsai14graphene.pdf), when running on Linux hosts. If Graphene is running inside an enclave, any system calls will cause #GP as you predict. System calls in enclaves will be handled in the future.

Thanks for the advice about adding the explanation in the Wiki. We will make the edit in the near future.

from graphene.

One more adventurous way to get this issue sorted out would be to somehow extend seccomp to allow user space handlers for system calls. In practice it would be non-trivial problem to find an upstreamable solution. Binary patching is doable and there exist a proof of concept for that i.e. Chromium. It's described here briefly: https://lwn.net/Articles/347547/. With Chromium of course the problem was more trivial because they control how the code is generated. You might think that this is a niche use case but think about statically linked binaries. They are completely ruled out. And one good application for Graphene might actually be to run some statically linked legacy binary.

from graphene.

I'm not saying that Graphene is unusable without support for various ways of doing a direct syscall. All I'm saying is that it's an obvious limitation :)

from graphene.

Thanks for the comment. Indeed, one of main reasons for us to add SECCOMP filter is to support static binaries, and certainly there are non-trivial amount of them. Graphene is not using binary patching now, but it is a feature we will actively explore in the future.

from graphene.

Hey, I wasn't aware that there was SECCOMP_RET_PTRACE. And it was added back in 2012 (commit fb0fadf9b).That is quite cool. I just read the seccomp documentation and found this out. Sorry for being ignorant in that part. That's why my previous comments about seccomp must have sounded like bit trippy :) I guess this is what you are using for non-SGX use case? Of course this doesn't sort out SGX part but stil is a great thing to have.

from graphene.

This can be safely closed after SGX related corner issues have been put into wiki page!

from graphene.

This whole thread seems to be greatly outdated so I'm closing it (static binary support was reworked and probably will change even more soon). Also, sandboxing support in Graphene was deprecated. If you want a two-way sandbox then just use a proper security sandbox and run Graphene inside.

from graphene.