[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200818145234.GC132200@linux.intel.com>
Date: Tue, 18 Aug 2020 17:52:34 +0300
From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>
Cc: Nathaniel McCallum <npmccallum@...hat.com>, x86@...nel.org,
linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
Andy Lutomirski <luto@...capital.net>,
Jethro Beekman <jethro@...tanix.com>,
Cedric Xing <cedric.xing@...el.com>, akpm@...ux-foundation.org,
andriy.shevchenko@...ux.intel.com, asapek@...gle.com, bp@...en8.de,
chenalexchen@...gle.com, conradparker@...gle.com,
cyhanish@...gle.com, dave.hansen@...el.com,
"Huang, Haitao" <haitao.huang@...el.com>,
Josh Triplett <josh@...htriplett.org>, kai.huang@...el.com,
"Svahn, Kai" <kai.svahn@...el.com>, kmoy@...gle.com,
ludloff@...gle.com, luto@...nel.org,
Neil Horman <nhorman@...hat.com>,
Patrick Uiterwijk <puiterwijk@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>, yaozhangx@...gle.com
Subject: Re: [PATCH v36 21/24] x86/vdso: Implement a vDSO for Intel SGX
enclave call
On Mon, Aug 10, 2020 at 03:23:17PM -0700, Sean Christopherson wrote:
> > This can be done implicitly by wrapping the struct
> > sgx_enclave_exception in another structure and then using techniques
> > like container_of() to find another field. However, this is made more
> > difficult by the fact that the sgx_enclave_exit_handler_t is not
> > really using the x86_64 sysv calling convention. Therefore, the
> > sgx_enclave_exit_handler_t MUST be written in assembly.
>
> What bits of the x86-64 ABI require writing the handler in assembly? There
> are certainly restrictions on what the handler can do without needing an
> assembly trampoline, but I was under the impression that vanilla C code is
> compatible with the exit handler patch. Is Rust more picky about calling
> convention?
>
> Side topic, the documentation for vdso_sgx_enter_enclave_t is wrong, it
> states the EFLAGS.DF is not cleared before invoking the handler, but that's
> a lie.
If handler requires the use of setjmp/longjmp API for sudden exits, that
is considered bad even with C++, as it is not compatible with stack
unwinding. The handler has a lot of constraints for its environment, and
is somewhat unappealing to use.
That's why I started today thinking a possibility of using a bpf program
as a middle-man. BPF programs can be used to execute code by the kernel
in behalf of user in a domain defined sandbox. The execution context is
just a buffer passed in R1 to the BPF interpreter. It can be defined by
application.
/Jarkko
Powered by blists - more mailing lists