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

["Xing, Cedric" <cedric.xing@intel.com>]

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
>>>> Linux.
>>>
>>> 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.

> 2. How is it simpler approach? There is a strong claim of simplicity
>     and convenience without anything backing it.

The major benefits in terms of simplicity realize in user mode 
applications. It's always a trade-off. This vDSO API takes 10-20 more 
lines than the original one but would save hundreds or even thousands in 
user applications.

Again, I don't want to repeat everything as you can look back at the 
lengthy discussion to dig out the details.

> 3. Why we need both register and stack based approach co-exist? I'd go
>     with one approach for a new API without any legacy whatsoever.

Neither is a legacy to the other. Supporting both approaches is by 
design. Again, the goal is to enable more vessels because there's *no* 
single best vessel.

> This really needs a better pitch before we can consider doing anything
> to it.
> 
> Also, in [2] there is talk about the next revision. Maybe the way go
> forward is to address the three issues I found in the cover letter
> and fix whatever needed to be fixed in the actual patches?
> 
> [1] https://lkml.org/lkml/2019/4/24/84
> [2] https://lkml.org/lkml/2019/4/25/1170

Let me update the commit message for the vDSO API and send you a patch.

> /Jarkko
>