[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1515784373.22302.492.camel@infradead.org>
Date: Fri, 12 Jan 2018 19:12:53 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Andi Kleen <andi@...stfloor.org>, tglx@...utronix.de
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, pjt@...gle.com,
torvalds@...ux-foundation.org, gregkh@...ux-foundation.org,
peterz@...radead.org, luto@...capital.net, thomas.lendacky@....com,
arjan.van.de.ven@...el.com
Subject: Re: Improve retpoline for Skylake
On Fri, 2018-01-12 at 10:45 -0800, Andi Kleen wrote:
> [This is an alternative to David's earlier patch to only
> handle context switch. It handles more cases.]
>
> Skylake needs some additional protections over plain RETPOLINE
> for Spectre_v2.
>
> The CPU can fall back to the potentially poisioned indirect branch
> predictor when the return buffer underflows.
>
> This patch kit extends RETPOLINE to guard against many (but not
> all) of such cases by filling the return buffer.
>
> - Context switch when switching from shallow to deeper call chain
> - Idle which clears the return buffer
> - Interrupts which cause deep call chains
>
> This is done with a new SPECTRE_V2 defense mode and feature flag.
>
> The mitigations are only enabled on Skylake, patched out
> on other CPUs.
Thanks for exploring what it would take to do this.
I admit I'm still not convinced. I think Skylake should probably just
default to IBRS (since the performance doesn't suck *quite* as much
there as it does on earlier CPUs) or give the user a command-line
option to use retpoline with the RSB-stuffing that is already
implemented.
Skylake still loses if it takes an SMI, right? Or encounters a call
stack of more than 16 in depth?
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)
Powered by blists - more mailing lists