Messages in this thread |  | | Subject | Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel | From | David Woodhouse <> | Date | Mon, 08 Jan 2018 10:45:17 +0000 |
| |
On Mon, 2018-01-08 at 02:34 -0800, Paul Turner wrote: > One detail that is missing is that we still need RSB refill in some > cases. > This is not because the retpoline sequence itself will underflow (it > is actually guaranteed not to, since it consumes only RSB entries > that it generates. > But either to avoid poisoning of the RSB entries themselves, or to > avoid the hardware turning to alternate predictors on RSB underflow. > > Enumerating the cases we care about: > > • user->kernel in the absence of SMEP: > In the absence of SMEP, we must worry about user-generated RSB > entries being consumable by kernel execution. > Generally speaking, for synchronous execution this will not occur > (e.g. syscall, interrupt), however, one important case remains. > When we context switch between two threads, we should flush the RSB > so that execution generated from the unbalanced return path on the > thread that we just scheduled into, cannot consume RSB entries > potentially installed by the prior thread.
Or IBPB here, yes? That's what we had in the original patch set when retpoline came last, and what I assume will be put back again once we *finally* get our act together and reinstate the full set of microcode patches.
> kernel->kernel independent of SMEP: > While much harder to coordinate, facilities such as eBPF potentially > allow exploitable return targets to be created. > Generally speaking (particularly if eBPF has been disabled) the risk > is _much_ lower here, since we can only return into kernel execution > that was already occurring on another thread (which could e.g. likely > be attacked there directly independent of RSB poisoning.) > > guest->hypervisor, independent of SMEP: > For guest ring0 -> host ring0 transitions, it is possible that the > tagging only includes that the entry was only generated in a ring0 > context. Meaning that a guest generated entry may be consumed by the > host. This admits:
We are also stuffing the RSB on vmexit in the IBRS/IBPB patch set, aren't we? [unhandled content-type:application/x-pkcs7-signature] |  |