Re: [PATCH v6 01/10] x86/retpoline: Add initial retpoline support

["Woodhouse, David" <dwmw@amazon.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On Tue, 2018-01-09 at 13:36 +0100, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 02:46:32PM +0100, Thomas Gleixner wrote:
> > On Mon, 8 Jan 2018, Josh Poimboeuf wrote:
> 
> > > I wonder if an error might be more appropriate than a warning.  I
> > > learned from experience that a lot of people don't see these Makefile
> > > warnings, and this would be a dangerous one to miss.
> > > 
> > > Also if this were an error, you could get rid of the RETPOLINE define,
> > > and that would be one less define cluttering up the already way-too-long
> > > GCC arg list.
> > 
> > It still allows to get the ASM part covered. If that's worth it I can't tell.
> 
> So elsewhere you stated we're dropping support for GCC without asm-goto
> (<4.5), does it then make sense to make one more step and mandate a
> retpoline capable compiler, which would put us at >=4.9 (for x86).
> 
> That would get rid of this weird case as well.

Yeah... I don't have strong feelings there.

Arjan (IIRC) had asked me to keep it this way.

The idea was that those were the *easy* targets for an attacker to
find; especially in entry_64.S it's asm all the way to the indirect
branch. A rootkit might be targeted at entirely unpatched systems which
leave that vulnerable, and *even* though there are other targets which
could be found with more work, doing just the asm code might well end
up protecting from such an attack in practice.

The CONFIG_RETPOLINE/!RETPOLINE case isn't really *that* much
complexity; I don't really care about that either.

On the whole, I'm inclined to leave it as it is without further
bikeshedding for now. We can change it later once all those GCC
releases have been made with the backports, perhaps.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5210 bytes --]