From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516692576; cv=none; d=google.com; s=arc-20160816; b=EclYKCOScNSS5td0Zdgpozs+C/oe03bpI5lY8W/wMYPxV0zT10c7r1Lac0iiCTx36v nSsIvDGoYdSjIg71xnbDm5dU3GTD84+qOsx0bQl4/z7mMQkVTZVF3S5/3Sk6fPxjns4i aa7hHVVkR/C2ZZeo9YKv5ZWs/pfdMFIcH8MRjWyjJRsX/51wtSfQiRbW/UNuOKkL7MzL gkRrcl7YrHBaWBEuW0PHUbMq8JJIAQrLqKf1ZrKSYILOAcfwp7VGDrwxcqMXEtCGkfq9 7IN6SGOVtaaGD80358JkzCG73XSEriltfvXC9iY5LFAm6w7u9ogYCgGaF6vmIhvNC5NO luUQ== 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:sender:dkim-signature :arc-authentication-results; bh=trSPNK+SB5FaHBFoLbiGSDGwpiwGGZ9xG9SfrhdVTro=; b=S5VQS6upMf7g1H5rn/6MVLbBurqNx/mcwoWIfsD0Jeu1wB9odnV8rJs9/FL7080on8 NTkhRUS8KuU9cG6U7G+qv8B9F/BesQJgo8NSNHrRwn8tGwk4PshnKE12moJLt3Jnktej gtqR5VW3viRdQvAUHBmD1tJGWOzB+BJwN2eOhRvLpR4rqBUXHuTCL+1wfrtO2fn3OJx9 Y1JcUBzAxlMMcOKG3EP90I602CDMCJYeh+AL2J8Lp01pdukBREfY4TOckXlDKsdMzy0G GLCTK73OnMBgJBgI4e+AD0yMHD4sf8jAphCIzcG58w0xi9EuLYDa9pA2/cnkPKP2um2o JthA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NoQT+kf/; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NoQT+kf/; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com X-Google-Smtp-Source: AH8x225oBzGa8uo/alhywDkYnaJcJPqj+x8TMXxyOToyyLwY2Ax/3/ay0EAiaTLevK/zpNvUV8pe0A== Sender: Ingo Molnar Date: Tue, 23 Jan 2018 08:29:30 +0100 From: Ingo Molnar To: David Woodhouse Cc: Linus Torvalds , KarimAllah Ahmed , Linux Kernel Mailing List , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , KVM list , the arch/x86 maintainers , Arjan Van De Ven Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Message-ID: <20180123072930.soz25cyky3u4hpgv@gmail.com> References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> <1516476182-5153-10-git-send-email-karahmed@amazon.de> <1516566497.9814.78.camel@infradead.org> <1516572013.9814.109.camel@infradead.org> <1516638426.9521.20.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516638426.9521.20.camel@infradead.org> User-Agent: NeoMutt/20170609 (1.8.3) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590367435488219595?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: * David Woodhouse wrote: > But wait, why did I say "mostly"? Well, not everyone has a retpoline > compiler yet... but OK, screw them; they need to update. > > Then there's Skylake, and that generation of CPU cores. For complicated > reasons they actually end up being vulnerable not just on indirect > branches, but also on a 'ret' in some circumstances (such as 16+ CALLs > in a deep chain). > > The IBRS solution, ugly though it is, did address that. Retpoline > doesn't. There are patches being floated to detect and prevent deep > stacks, and deal with some of the other special cases that bite on SKL, > but those are icky too. And in fact IBRS performance isn't anywhere > near as bad on this generation of CPUs as it is on earlier CPUs > *anyway*, which makes it not quite so insane to *contemplate* using it > as Intel proposed. There's another possible method to avoid deep stacks on Skylake, without compiler support: - Use the existing mcount based function tracing live patching machinery (CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack depth tracking tracer which would issue a retpoline when stack depth crosses boundaries of ~16 entries. The overhead of that would _still_ very likely be much cheaper than a hundreds (thousands) of cycle expensive MSR write at every kernel entry (syscall entry, IRQ entry, etc.). Note the huge number of advantages: - All distro kernels already enable the mcount based patching options, so there's literally zero overhead to anything except SkyLake. - It is fully kernel patching based and can be activated on Skylake only - It doesn't require any microcode updates, so it will work on all existing CPUs with no firmware or microcode modificatons - It doesn't require any compiler updates - SkyLake performance is very likely to be much less fragile than relying on a hastily deployed microcode hack - The "SkyLake stack depth tracer" can be tested on other CPUs as well in debug builds, broadening the testing base - The tracer is very obviously simple and reviewable, and we can forget about it in the far future. - It's much more backportable to older kernels: should there be a new class of exploits then this machinery could be updated to cover that too - while upgrades to newer kernels would give the higher performant solution. Yes, there are some practical complications like always enabling CONFIG_FUNCTION_TRACER=y on x86, plus the ftrace interaction has to be sorted out, but in practice it's enabled on all major distros anyway, due to ftrace. Is there any reason why this wouldn't work? Thanks, Ingo