lkml.org 
[lkml]   [2020]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
On Tue, Sep 29, 2020 at 12:52:35AM +0100, Andrew Cooper wrote:
> On 28/09/2020 21:42, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 05:44:35PM +0100, Andrew Cooper wrote:
> >> On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> >>> On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> >>>> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> >>>>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>>>> new file mode 100644
> >>>>> index 000000000000..adbd59d41517
> >>>>> --- /dev/null
> >>>>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>>>> @@ -0,0 +1,157 @@
> >>>>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> >>>>> <snip>
> >>>>> +.Lretpoline:
> >>>>> + call 2f
> >>>>> +1: pause
> >>>>> + lfence
> >>>>> + jmp 1b
> >>>>> +2: mov %rax, (%rsp)
> >>>>> + ret
> >>>> I hate to throw further spanners in the work, but this is not compatible
> >>>> with CET, and the user shadow stack work in progress.
> >>> CET goes beyond my expertise. Can you describe, at least rudimentary,
> >>> how this code is not compatible?
> >> CET Shadow Stacks detect attacks which modify the return address on the
> >> stack.
> >>
> >> Retpoline *is* a ROP gadget.  It really does modify the return address
> >> on the stack, even if its purpose is defensive (vs Spectre v2) rather
> >> than malicious.
> > Aah. I get that, yes.
> >
> > Kernel is full of retpoline but I presume that ring-0 does not use CET.
>
> No-one has implemented support CET-SS support for Linux itself yet, but
> other kernels do have it working.
>
> ~Andrew

Haitao, can you point out the user handler callback in the Intel
SGX runtime?

There is only one single global callback in a practical deployment
provided by the runtime. AFAIK, it just copies values, does not do any
rountrips and is generally very trivial peace of code but it is better
to check it before final say.

I've now experimented with ALTERNATIVE() and it can be definitely made
work. I'm just thinking that would it be best not use retpoline at all?

My guess is that the callback would not have much applicability in
Spectre'ish attacks but do not have enough expertise on that to even
semiformally conclude it.

My intention is to find reasonable conclusions to drop it instead of
adding more complexity to the vDSO.

/Jarkko

\
 
 \ /
  Last update: 2020-09-30 02:53    [W:0.167 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site