On Mon, Jan 8, 2018 at 2:38 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Mon, 8 Jan 2018, Paul Turner wrote: > >> 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. > > I am still unclear whether this closes it completely, as when HT is on, > the RSB is shared between the threads, right? Therefore one thread can > poision it for the other without even context switch happening. >
See 2.6.1.1 [Replicated resources]: "The return stack predictor is replicated to improve branch prediction of return instructions" (This is part of the reason that the sequence is attractive; its use of the RSB to control prediction naturally prevents cross-sibling attack.) > -- > Jiri Kosina > SUSE Labs >
