Re: [PATCH v19,RESEND 24/27] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

[Andy Lutomirski]

On Sun, Mar 24, 2019 at 1:59 AM Xing, Cedric <cedric.xing@xxxxxxxxx> 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.