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@xxxxxxxxxxxxxx > > 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:
smime.p7s
Description: S/MIME Cryptographic Signature
