Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753749AbeAJBeg (ORCPT + 1 other); Tue, 9 Jan 2018 20:34:36 -0500 Received: from one.firstfloor.org ([193.170.194.197]:40868 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752784AbeAJBef (ORCPT ); Tue, 9 Jan 2018 20:34:35 -0500 Date: Tue, 9 Jan 2018 17:34:33 -0800 From: Andi Kleen To: Andy Lutomirski Cc: Andi Kleen , tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, dwmw@amazon.co.uk, pjt@google.com, luto@kernel.org, peterz@infradead.org, thomas.lendacky@amd.com, tim.c.chen@linux.intel.com, gregkh@linux-foundation.org, dave.hansen@intel.com, jikos@kernel.org Subject: Re: x86/clearregs: Register sanitizing at kernel entry for speculation hygiene Message-ID: <20180110013433.mmw7j3uy7xod5e25@two.firstfloor.org> References: <20180110010328.22163-1-andi@firstfloor.org> <50B38CB9-546E-4419-9162-D6A2AC2D80C3@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B38CB9-546E-4419-9162-D6A2AC2D80C3@amacapital.net> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > I don't like this at all. Once upon a time, Linux syscalls were supposed to be fast. Then we learned about the Meltdown screwup, so we mostly fixed it for real upstream and the distroa seriously half-arsed their own fixes [1]. This came with a big performance cost, but it can be turned off on non-busted hardware. So be it. That's true, but modern CPUs are also a lot faster/wider than the K8 the fast path was originally designed for. A modern CPU can go through these instructions really fast with a very high IPC because they don't have dependencies or stalls. So it shouldn't hurt very much. Also in fact when the fast path was originally written the ABI still had a different caller/callee split which made it more better. Later on it already lost some of its benefits and was less of a win. > But now we're proposing to throw out the whole fast path because it might make it a bit harder to do the most obvious attack. Not very hard, mind you, but a little bit harder. And there's no off switch for less-leaky hardware. No thanks. Well the off switch is a fast CPU. -Andi