Re: [PATCH] x86/vdso: Remove retpoline from SGX vDSO call

From: Jethro Beekman <jethro@fortanix.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-sgx@vger.kernel.org, x86@kernel.org,
	Haitao Huang <haitao.huang@linux.intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Cedric Xing <cedric.xing@intel.com>
Subject: Re: [PATCH] x86/vdso: Remove retpoline from SGX vDSO call
Date: Wed, 30 Sep 2020 19:01:18 +0200	[thread overview]
Message-ID: <f5021328-2fab-a404-108f-e28e26e6996c@fortanix.com> (raw)
In-Reply-To: <17231664-3735-2d57-fbfa-9af838e224ab@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

On 2020-09-30 18:28, Dave Hansen wrote:
> On 9/30/20 8:43 AM, Sean Christopherson wrote:
>>>> Do you recall why you added it in the first place?  What was the
>>>> motivation for it?  Were you responding to a review comment?
>>> Absolutely cannot recall it :-) I even cannot recall the exact time when
>>> we landed the vDSO in the first place. Too much stuff has happend during
>>> the long three year upstreaming cycle. I will try to backtrack this
>>> info.
>> It originated in a comment from Andy when we were discussing the legitimacy
>> of the callback.  From that point on it got taken as gospel that the indirect
>> call would be implemented as a retpoline.
>>
>> https://lkml.kernel.org/r/CALCETrVBR+2HjTqX=W4r9GOq69Xg36v4gmCKqK0wUjzAqBJnrw@mail.gmail.com
> 
> OK, so that was Andy L. saying:
> 
>> But I have a real argument for dropping exit_handler: in this new age
>> of Spectre, the indirect call is a retpoline, and it's therefore quite
>> slow.  So I'm not saying NAK, but I do think it's unnecessary.
> 
> It sounds like we were never able to jettison the indirect call.  So,
> we've got a kernel-provided indirect call that's only ever executed by
> userspace.  A quick grep didn't show any other indirect branches in the
> VDSO, so there might not be good precedent for what to do.
> 
> The problem with the VDSO is that even if userspace is compiled to the
> gills with mitigations, this VDSO branch won't be mitigated since it
> comes from the kernel.
> 
> So, here's the big question for me:  How does a security-sensitive
> userspace *binary* make mitigated indirect calls these days?
> 
> Seems like the kind of thing for which Intel should have a good writeup.  :)
> 

If by "these days" you mean also protecting against LVI, then it'd be like so, I think:

lfence 
callq  *%rax

(at least this is what the LLVM LVI hardening pass does)

--
Jethro Beekman | Fortanix

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4490 bytes --]