On Wed, 31 Oct 2018, Sean Christopherson wrote:
On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
On 10/01/2018 02:42 PM, Jethro Beekman wrote:
1) Even though the vDSO function exists, userspace may still call
`ENCLU[EENTER]` manually, so the fault handling as described in the
current patch should also be maintained.
Why?
Circling back to this question, what if we take the easy way out and
simply signal SIGSEGV without an SGX-specific code? I.e. treat #PF
with X86_PF_SGX as an access error, no more no less. That should be
sufficient for userspace to function, albeit with a little more effort,
but presumably no more than would be needed to run on SGX1 hardware.
AFAIK there isn't a way to prevent userspace from manually invoking
EENTER, short of doing some really nasty text poking or PTE swizzling.
We could declare using EENTER as unsupported, but that seems like
cutting off the nose to spite the face. Supporting userspace EENTER
in a limited capacity would allow people to do whatever crazy tricks
they're wont to do without having to deal with absurd requests for
the vDSO interface.
If we go this route we could also add the vDSO stuff after basic SGX
support is in mainline, obviously with approval from the powers that
be.
Yeah, this would give stable behavior when vDSO functions are not
available.
Here's a question: if we implement this behavior, could be upstream
series without vDSO's first and after those changes have been landed
we would continue with the vDSO's?
/Jarkko
