Re: [RFC PATCH v3 0/4] x86: Add exception fixup for SGX ENCLU

["Dr. Greg" <greg@enjellic.com>]

On Tue, Dec 11, 2018 at 03:10:52PM -0800, Andy Lutomirski wrote:

Good evening, I hope the day has gone well for everyone.

> > > > On Dec 11, 2018, at 8:52 AM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> > > >
> > > > This isn't fundamentally different than forcing all EENTER
> > > > calls through the vDSO, which is also per-process.
> > > > Technically this is more flexible in that regard since
> > > > userspace gets to choose where their one ENCLU gets to reside.
> > > > Userspace can have per-enclave entry flows so long as the
> > > > actual ENLU[EENTER] is common, same as vDSO.

> > > Right. The problem is that user libraries have a remarkably hard
> > > time agreeing on where their one copy of anything lives.

> > Are you concerned about userspace shooting themselves in the foot,
> > e.g.  unknowingly overwriting their handler?  Requiring
> > unregister->register to change the handler would mitigate that
> > issue for the most part.  Or we could even say it's a write-once
> > property.
> >
> > That obviously doesn't solve the issue of a userspace application
> > deliberately using two different libraries to run enclaves in a
> > single process, but I have a hard time envisioning a scenario
> > where someone would want to use two different *SGX* libraries in a
> > single process.  Don't most of the signal issue arise due to
> > loading multiple libraries that provide *different* services
> > needing to handle signals?

> I can easily imagine two SGX libraries that know nothing about each
> other running in the same process.  One or both could be PKCS#11
> modules, for example.

Very good, I see that Sean agreed with this down thread.  I was
concerned that our discussion was lacking precision and we were
talking past one another.

> I suspect that Linux will eventually want the ability for libraries
> to register exception handlers, but that's not going to get designed
> and implemented quickly enough for SGX's initial Linux rollout.  A
> vDSO helper like in your earlier series should solve most of the
> problem without any contention issues.

Let me see if I can impart some framework for additional clarity as
discussions proceed forward.

I believe it would be helpful if we could agree to refer to a body of
code, possibly in library form, that loads, initializes and executes
an enclave as an 'SGX runtime'.  In this framework, the term 'library'
refers to code that an application links to for domain specific
functionality, ie. libpkcs11, libkrb5, libsasl.  These 'libraries' may
implement enclaves, using 'SGX runtimes' of their choice, to improve
their security guarantees.

In this model it is the 'SGX runtime' that is responsible for
registering SGX exception handlers under their management.

In order for mainline Linux SGX support to be relevant, it must admit
mutually distrusting 'SGX runtimes' in the same process context.  The
SGX exception handler architecture must also support the notion of
'nested enclave' invocation where an enclave may execute an OCALL and
then go on to execute an enclave, possibly based on a different 'SGX
runtime', before returning into its previous enclave.

Hopefully the above will help assist further discussions.

Have a good evening.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"If you think nobody cares if you're alive, try missing a couple of car
 payments."
                                -- Earl Wilson