[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <721ca14e-21df-3df1-7bef-0b00d0ff90c3@citrix.com>
Date: Fri, 25 Sep 2020 19:23:59 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
<x86@...nel.org>, <linux-sgx@...r.kernel.org>
CC: <linux-kernel@...r.kernel.org>,
Sean Christopherson <sean.j.christopherson@...el.com>,
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>, <haitao.huang@...el.com>,
<josh@...htriplett.org>, <kai.huang@...el.com>,
<kai.svahn@...el.com>, <kmoy@...gle.com>, <ludloff@...gle.com>,
<luto@...nel.org>, <nhorman@...hat.com>, <npmccallum@...hat.com>,
<puiterwijk@...hat.com>, <rientjes@...gle.com>,
<tglx@...utronix.de>, <yaozhangx@...gle.com>,
"H.J. Lu" <hjl.tools@...il.com>,
Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX
enclave call
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.
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.
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
Powered by blists - more mailing lists