From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226Jdb4146OLeShvm9DSdfXpM86vM/iR8ge4YzEAF2DCOs0NNNV8a3ebUNLQXdAJ5lv5Se7h ARC-Seal: i=1; a=rsa-sha256; t=1516899959; cv=none; d=google.com; s=arc-20160816; b=OPvsoPCm8yTY+rNTSXOfkuQs3zJMni4UhEYK1n1JGvQ2HUA1lesEC/VZAJaKLDM+N9 NVvMhor3nGxtX+4iGHFEiCLxc8Y/dd21e5UHkMlsJmXkWPqdSRYUvJyzPMrbHRyqCTTU rnbN8YY+YCmgjQqUn6qv4rh0/m7VqwJfPQMj938GrhOqewW1+qhg8QAdZrighdJcDpIf dF612Sh5wC5sZ6z8eRaXkB35uoxitdlkTenoe7g/nRjpGw76oc/aU9d0KYBXT96z2r7t eQbWcdeBi1Felttxm4jzF3QwFZVrFIKXhxkg+Z6sgqST1C7uqsfGldWz6zuhW9VrsOsN WIUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dmarc-filter:arc-authentication-results; bh=mrjnRcOGle3M82YwzzhXZrbElwnRKGlw9EhAe2s5+uY=; b=1AVrxqS8PI3hyQcVo5pZzYaoB9JQJG6eHEDQvfzYdowNaJdLS4mws/qLpQ+sCvy3kS tVioD8pNKlIQZYfwDNDxsO3QJhgzQ+/JdqgoAQSLYrozUIp0hLHAa/9g4ewAzX+6oO6E fA8NtpcF4PbwYR95ymWvx/W7XnMB0caKhbXnwRUDLlFN1e+l5x3foB3Fuj7ybCRCM35c GCii40WEoM1ZLfYmlFue7R031RgAvgAsSKu0WBJLcbqvJf6+mQblh/pqYOjpz1xjbVlT fDC0+L9/qV5PLP3jtRQL30ouHavkbbRztEGQx3HkOAM9oWzBlcLtU8AcQNHpDs0aCgDS +/cg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD266217AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: <1516899639.30244.145.camel@infradead.org> References: <1515755487-8524-1-git-send-email-dwmw@amazon.co.uk> <20180125120743.ey32gvl5mjam4r2s@pd.tnic> <1516882849.30244.94.camel@infradead.org> <20180125124554.vdx7rrnfrxrzl2ng@pd.tnic> <20180125151024.bidjr26r667vs7h5@treble> <20180125155110.mw655b7fwgm7qqc7@pd.tnic> <1516896198.30244.133.camel@infradead.org> <20180125165646.ytc4upthpaqtwi45@treble> <1516899639.30244.145.camel@infradead.org> From: Andy Lutomirski Date: Thu, 25 Jan 2018 09:05:37 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [tip:x86/pti] x86/retpoline: Fill return stack buffer on vmexit To: David Woodhouse Cc: Josh Poimboeuf , Borislav Petkov , Tim Chen , Paul Turner , Jiri Kosina , Greg Kroah-Hartman , Dave Hansen , Ingo Molnar , Rik van Riel , Linus Torvalds , Andi Kleen , Kees Cook , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , LKML , linux-tip-commits@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589334225298273984?= X-GMAIL-MSGID: =?utf-8?q?1590584891193504938?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, Jan 25, 2018 at 9:00 AM, David Woodhouse wrote: > On Thu, 2018-01-25 at 10:56 -0600, Josh Poimboeuf wrote: >> On Thu, Jan 25, 2018 at 04:03:18PM +0000, David Woodhouse wrote: >> > On Thu, 2018-01-25 at 16:51 +0100, Borislav Petkov wrote: >> > > >> > > > And the seg fault is objtool's way of telling you you need a >> > > > ANNOTATE_NOSPEC_ALTERNATIVE above the alternative ;-) >> > > >> > > Except that it blew up when I did this which doesn't have ALTERNATIVE >> > > (it's the diff I saved :-)) >> > >> > Yeah, ANNOTATE_NOSPEC_ALTERNATIVE just tells objtool "don't look at the >> > alternative; you're not going to like it". >> > >> > If you start putting a __fill_rsb() function out of line somewhere and >> > only *calling* it from alternatives, then objtool is going to shit >> > itself when it sees that function, regardless. >> >> Right, if you *really* want it always inline, the short term solution is >> to just patch it in with X86_FEATURE_ALWAYS. > > And the whole problem here is that patching it in with alternatives is > painful on kernels < 4.1 because back then, we didn't cope with > oldinstr and altinstr being different lengths. > > And they don't want to fix *that* because kABI... > > I just stopped caring. Screw kABI. Distros that use retpolines need their driver vendors to recompile no matter what. Distros that use IBRS and refuse to use retpolines should get put on a list of "didn't actually adequately mitigate spectre".