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? I know CET only conceptual level (separate stack holding return addresses as an measure against return oriented programming (ROP)). > Whichever of these two large series lands first is going to inflict > fixing this problem on the other. > > As the vdso text is global (to a first approximation), it must not be a > retpoline if any other process is liable to want to use CET-SS. Why is that? > If the retpoline really does need to stay, then the vdso probably needs > to gain suitable __x86_indirect_thunk_%reg thunks which are patched at > boot based on the system properties. > > ~Andrew aka without CET it is patched? With CET, not? /Jarkko
