Re: Avoid speculative indirect calls in kernel

[Alan Cox]

> But then, exactly because the retpoline approach adds quite some cruft
> and leaves something to be desired, why even bother?  Intel has also

Performance

> Also, according to Google the KVM PoC can be broken simply by clearing
> the registers on every exit to the hypervisor.  Of course it's just
> mitigation, but perhaps _that_ is where we should start fixing the
> user/kernel boundary too.

The syscall boundary isn't quite that simple and clearing registers make
things harder but not impossible. It's a good hardening exercise as are
things like anding the top bit off userspace addresses on x86 64bit so
that even if someone speculates through a user copy they get to steal
their own data.

Other hardening possibilities include moving processes between cores,
yielding to another task for a bit or clearing L1 data if a syscall
returns an error, running only processes for the same uid on hyperthreaded
pairs/quads (more easy to do with VMs and something some cloud folk kind
of do anyway so that you more clearly get what you pay for in CPU time)
etc

Buffer overruns went from fly swatting, through organized analysis,
hardening, tools, better interfaces and language changes. History usually
repeats itself.

But absolutely - yes we should be looking at effective hardening
mechanisms in the kernel just as people will be in the hardware.

Alan