On Sun, Mar 24, 2019 at 1:59 AM Xing, Cedric <cedric.x...@intel.com> wrote: > > Hi Andy, > > Thank you for your valuable feedbacks! > > Per what you have been saying, your feedbacks come from different angles - > i.e. functionality vs. security, but they are mixed up somehow.
I think you're misunderstanding me. I'm not talking about security at all here. SGX isn't a sandbox, full stop. I'm talking about the degree to which an SGX enclave acts like a well-behaved black box. > > > I’m going to put my vDSO maintainer hat on for a minute. Cedric, your > > proposal has the following issues related specifically to the vDSO: > > > > It inherently contains indirect branches. This means that, on retpoline > > configurations, it probably needs to use retpolines. This is doable, > > but it’s nasty, and you need to worry about register clobbers. > > Only the weakest link matters in security. With dynamic linking in use, this > additional indirect CALL can't make things worse. But I'm open to, and in > fact also willing to, apply whatever mitigation that you think is > satisfactory (or that has been applied to other indirect branches, such as in > PLT), such as retpoline. Btw, don't worry about register clobbers because we > have at least %rax at our disposal. There is no actual fundamental reason that dynamic linking has to work this way, and in principle, one could even use retpolines to the call the vDSO. In any event, the vDSO is currently compiled with retpolines enabled, and if we decide to turn that off, it would be decision to be made independently of SGX. > > > > > It uses effectively unbounded stack space. The vDSO timing functions are > > already a problem for Go, and this is worse. > > If targeting the same functionality (i.e. no exit callback), my API uses > exactly 24 bytes more than Sean's. Is it really the case that those 24 bytes > will break Go? You're counting wrong. Your version uses 24 bytes + the stack size of the exit handler + the amount of stack consumed by the enclave, which is effectively unbounded. So this whole scheme becomes unusable on anything other than a stack that is "large" for a totally undefined value of large and that has guard pages. > > > > > Cedric, your proposal allows an enclave to muck with RSP, but not in a > > way that’s particularly pleasant. > > From security perspective, it is SGX ISA, but NOT any particular ABI, that > allows enclaves "to muck with RSP". Again, this has nothing to do with security. With your proposal, it's not possible for the caller of an enclave to decide, in an ocall handler, to pause and do something else. This isn't just theoretical. Suppose someone wants to send a network request in an ocall handler. With the current RSP approach, it's difficult to do this in a program that uses poll / select / epoll -- you can't return out from the ocall until you have an answer.
