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. :)
