From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224YLPA3aXG/g9SWJM8nyKRa//vUgWSSJk1Lftqm/pjkkTBk2M+bvH5Hu3Znaduz4QVoDaIy ARC-Seal: i=1; a=rsa-sha256; t=1517207746; cv=none; d=google.com; s=arc-20160816; b=oAkTMMsEYn/IFa20ArFM+t3RHHSN6c/syernBB2fyH+J7U2TuUyFD8hBka4I68Mnpt HD6tcpm6IKP6aDwY0OdEmFPBW8+SE9IIVybqeh1AYtBvPG/sZQTbSrB/Y2pAyOIZs8hT 6LltuFRolU79oLCApEnt+qV7JxBC3LUpOgyoOW/F4zmiHiKyf2JGhQjd6fxoBMryN5QJ OikRWbuqXsPql5D0AWmU8ff7B9O+CuuHfCbekZBpaCKBAtajunOZBMFbRW3TIxPqGvVh dx2gAlO45gcJw6jCDd6aj5agBPbY3iJibiDgyIG0iaOXHGPkL5U57WSfp5fCNWoGlTz4 jktA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:organization:from:cc:references:to :arc-authentication-results; bh=MsDL5RZ3XLfmtLLIJ87lPWX94e4xZF/ObKRUiufcB38=; b=yrRYOdtL8pDslaCOCpZ4XWFnFkmieYK0hUAXVkkhc4qQBlYeR7SbH0QxZX3WyAMkwJ VThbG/q8xbC37l/+G5bsQfAhaOp7FPRZphlXM5GncEUJvk8OiyEqAAUIvPKchgoPkHnW PRomjyYaE4ggAl0YknQ+JD/V+qAGWu/1s1i526kJtxc+2SFNP9KgDa31p8nUZaS1AyZF 8yj+upLOroYWhvVXY0pJh9QgAl0SZaz8YVsIlvvbVCPuWiKjtYLsJWgZGGnwpcIEEStr 9iT3z8D4FkeMLDhBjsHFsQLx4dqv4t1omQ/QhZ8n0dA8sSn7ItP2C8kp5VqJ0o6PdENr 5xcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of jcm@jonmasters.org designates 173.255.233.168 as permitted sender) smtp.mailfrom=jcm@jonmasters.org Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of jcm@jonmasters.org designates 173.255.233.168 as permitted sender) smtp.mailfrom=jcm@jonmasters.org To: Peter Zijlstra , KarimAllah Ahmed References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> <1516476182-5153-5-git-send-email-karahmed@amazon.de> <20180121112224.GH2269@hirez.programming.kicks-ass.net> Cc: linux-kernel@vger.kernel.org, Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , David Woodhouse , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , kvm@vger.kernel.org, x86@kernel.org From: Jon Masters Organization: World Organi{s,z}ation Of Broken Dreams Message-ID: Date: Mon, 29 Jan 2018 01:35:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20180121112224.GH2269@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 173.164.135.226 X-SA-Exim-Mail-From: jcm@jonmasters.org Subject: Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process X-SA-Exim-Version: 4.2.1 (built Sun, 08 Nov 2009 07:31:22 +0000) X-SA-Exim-Scanned: Yes (on edison.jonmasters.org) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140567714479425?= X-GMAIL-MSGID: =?utf-8?q?1590907629085085588?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Hi Peter, David, all, First a quick note on David's earlier comment, about this optimization being still up for debate. The problem with this optimization as-is is that it doesn't protect userspace-to-userspace unless applications are rebuilt and we get the infrastructure to handle that (ELF, whatever). But... On 01/21/2018 06:22 AM, Peter Zijlstra wrote: > On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote: >> From: Tim Chen >> >> Flush indirect branches when switching into a process that marked >> itself non dumpable. This protects high value processes like gpg >> better, without having too high performance overhead. > > So if I understand it right, this is only needed if the 'other' > executable itself is susceptible to spectre. If say someone audited gpg > for spectre-v1 and build it with retpoline, it would be safe to not > issue the IBPB, right? More importantly, rebuilding the world introduces a lot of challenges that need to be discussed heavily before they happen (I would like to see someone run a session at one of the various upcoming events on userspace, I've already prodded a few people to nudge that forward). In particular, we don't have the infrastructure in gcc/glibc to dynamically patch userspace call sites to enable/disable retpolines. We discussed nasty hacks last year (I even suggested an ugly kernel exported page similar to VDSO that could be implementation patched for different uarches), but the bottom line is there isn't anything in place to provide a similar userspace experience to what the kernel can do, and that would need to be solved in addition to the ELF/ABI bits. > So would it make sense to provide an ELF flag / personality thing such > that userspace can indicate its spectre-safe? > > I realize that this is all future work, because so far auditing for v1 > is a lot of pain (we need better tools), but would it be something that > makes sense in the longer term? So I would just caution that doing this isn't necessarily bad, but it's far more than just ELF bits and rebuilding. Once userspace is rebuilt with un-nopable retpolines, they're there whether you need them on $future_hardware or not, and that fancy branch predictor is useless. So we really need a way to allow for userspace patchable calls, or at least some kind of plan before everyone runs away with rebuilding. (unless they're embedded/Gentoo/whatever...have fun in that case) Jon. P.S. This is why for certain downstream distros you'll see IBPB use like prior to this patch - it'll prevent certain attacks that can't be otherwise mitigated without going and properly solving the tools issue.