From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226fFIscdI1L0fT1/2EbE4oLgSkgRQte3bUZmM1Miy/DRn7gg8IEUTlpgvP5HfiT9TqOz31k ARC-Seal: i=1; a=rsa-sha256; t=1516902253; cv=none; d=google.com; s=arc-20160816; b=AbJF7rVmnWYZ52XqIhmRCYGmETQNhQrE5YN5Fe1kPbJ/HaSKnT7Uygb62uXC4nTdLr 0tZACwHWBFiRZllaF4VPRStM1eD/enb+GqWIpAQiNj3qo78H29ItZVNxlxlddd4+nKgW D8bSmRwkDu0BkRiorrNNWJAyBjV9ias+FZ05yzX7ePWBU6qQ4XG6v3954O0Ll46mWNMj BMGRpnhnx9BZPDZQrqfoEhY6Y3UfkGzjtmKjF3ifvP8V0z3UZGdMFp5di2ntrYfCGgoh 9YQ50iWbMzBFZDOolXDvP8aLnSbmGL7GL/XlzAl6Mvqwt4W1bucKiu5vAEDQB+v57i0u 91Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=8dbzazfogZirHKh2r+QrvRVFuuoYZVmbEpYqutb8wq4=; b=QECONKqANVXL+0N30M1yk3gyxZp+TVSdr0vit/i71y8HdfHcvY3ajYrqxt6Q4vLjcI WSfiZ9mZwqelAWwX4Zx+i8jo04y3vunGhcT30bTOTEeqF86+VDtiDxNWU1BnQRt/iz1d 8FoNXsC2c5gUkTlowcy6/7Dxv8ScqeLZv+QkG7T2x+xE7Dt5feGzH0Cxv4ax/kmp5vW/ k5pZz2wxK5F7cSG8g3FGlPlOJY1B4W7sAhiw7zMIf6v74AQkcuQR2wYsimGHAJ0D63L8 gx44vSpN+ijAY50LWNNV4UuR3Z+IGrhs9osltjcNapvjqX3C1EuLxP3RlkXa6aseL4g+ o2Jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jpoimboe@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jpoimboe@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of jpoimboe@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jpoimboe@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Date: Thu, 25 Jan 2018 11:44:06 -0600 From: Josh Poimboeuf To: Andy Lutomirski Cc: David Woodhouse , 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 Subject: Re: [tip:x86/pti] x86/retpoline: Fill return stack buffer on vmexit Message-ID: <20180125174406.wxdibcyqv724uuun@treble> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589334225298273984?= X-GMAIL-MSGID: =?utf-8?q?1590587297585506550?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, Jan 25, 2018 at 09:05:37AM -0800, Andy Lutomirski wrote: > 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. There are *many* real world users who depend on kABI, so it's a fact of life with no better known solution for the given constraints. If you have a better idea then I suggest you build your own enterprise distro. > 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". Retpolines don't need to break kABI. We can just detect when they're missing and report it to the user. And I don't think there's anybody *refusing* to use retpolines, is there? But they're still not fully baked, especially for Skylake+. IBRS was just easier to implement out of the gate. And it mitigates Spectre just fine, but it's too slow to stick with long term. -- Josh