Messages in this thread |  | | Subject | Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel | Date | Wed, 10 Jan 2018 15:20:45 +0000 | From | "Woodhouse, David" <> |
| |
On Mon, 2018-01-08 at 02:42 -0800, Paul Turner wrote: > > While the cases above involve the crafting and use of poisoned > entries. Recall also that one of the initial conditions was that we > should avoid RSB underflow as some CPUs may try to use other indirect > predictors when this occurs.
I think we should start by deliberately ignoring the CPUs which use the other indirect predictors on RSB underflow. Those CPUs don't perform *quite* so badly with IBRS anyway.
Let's get the minimum amount of RSB handling in to cope with the pre- SKL CPUs, and then see if we really do want to extend it to make SKL 100% secure in retpoline mode or not.
So let's go through your list of cases and attempt to distinguish the underflow concerns (which I declare we don't care about for now) from the pollution (which we care about especially for non-SMEP) concerns...
> The cases we care about here are: > - When we return _into_ protected execution. For the kernel, this > means when we exit interrupt context into kernel context, since may > have emptied or reduced the number of RSB entries while in iinterrupt > context.
Don't care about that particular example. That's underflow-only.
However, we *do* care about entry to kernel code from userspace, for interrupts and system calls etc. Basically everywhere that the IBRS code would be setting IBRS, we need to flush the RSB (if !SMEP, I think).
> - Context switch (even if we are returning to user code, we need to > at unwind the scheduler/triggering frames that preempted it > previously, considering that detail, this is a subset of the above, > but listed for completeness)
Don't care. This is underflow-only. (Which means I think we want to drop Andi's patch?)
> - On VMEXIT (it turns out we need to worry about both poisoned > entries, and no entries, the solution is a single refill > nonetheless).
Do care. This fixes pollution from the guest, and even SMEP isn't enough to make us not care.
> - Leaving deeper (>C1) c-states, which may have flushed hardware > state
Don't care.
> - Where we are unwinding call-chains of >16 entries[*]
Don't care.
Overall, I think the RSB-stuffing is needed in all the same places that it's needed with IBRS.[unhandled content-type:application/x-pkcs7-signature] |  |