Messages in this thread |  | | Date | Mon, 8 Jan 2018 12:49:39 -0000 | Subject | Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel | From | "David Woodhouse" <> |
| |
> On Mon, Jan 8, 2018 at 2:45 AM, David Woodhouse <dwmw2@infradead.org> > wrote: >> 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. > > IBPB is *much* more expensive than the sequence I suggested. > If the kernel has been protected with a retpoline compilation, it is > much faster to not use IBPB here; we only need to prevent > ret-poisoning in this case.
Retpoline protects the kernel but IBPB is needed on context switch anyway to protect userspace processes from each other.
But...
> A) I am enumerating all of the cases for completeness. It was missed > by many that this detail was necessary on this patch, independently of > IBRS. > B) On the parts duplicated in (A), for specifics that are contributory to > correctness in both cases, we should not hand-wave over the fact that > they may or may not be covered by another patch-set. Users need to > understand what's required for complete protection. Particularly if they > are backporting.
... yes, agreed. Now we are putting retpoline first we shouldn't miss things that we *were* doing anyway. TBH I really don't think we should have spilt the patch sets apart; we'll work on getting the rest on top ASAP.
-- dwmw2
|  |