Re: [RFC PATCH v2 0/3] An alternative __vdso_sgx_enter_enclave() to allow enclave/host parameter passing using untrusted stack

From: Xing, Cedric
Date: Thu Jul 11 2019 - 15:51:17 EST

On 7/11/2019 2:38 AM, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 04:37:41PM -0700, Xing, Cedric wrote:
On 7/10/2019 4:15 PM, Jarkko Sakkinen wrote:
On Thu, Jul 11, 2019 at 01:46:28AM +0300, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 11:08:37AM -0700, Xing, Cedric wrote:
With these conclusions I think the current vDSO API is sufficient for

The new vDSO API is to support data exchange on stack. It has nothing to do
with debugging. BTW, the community has closed on this.

And how that is useful?

The CFI directives are for stack unwinding. They don't affect what the code
does so you can just treat them as NOPs if you don't understand what they
do. However, they are useful to not only debuggers but also exception
handling code. libunwind also has a setjmp()/longjmp() implementation based
on CFI directives.

Of course I won't merge code of which usefulness I don't understand.

I re-read the cover letter [1] because it usually is the place
to "pitch" a feature.

It fails to address two things:

1. How and in what circumstances is an untrusted stack is a better
vessel for handling exceptions than the register based approach
that we already have?

We are not judging which vessel is better (or the best) among all possible
vessels. We are trying to enable more vessels. Every vessel has its pros and
cons so there's *no* single best vessel.

I think reasonable metric is actually the coverage of the Intel SDK
based enclaves. How widely are they in the wild? If the user base is
large, it should be reasonable to support this just based on that.

I don't know how many existing enclaves out there, but definitely larger than 0 (zero), while user base for the old API is definitely 0. What are you worrying, really?