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
