Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751355AbeAPAlr (ORCPT + 1 other); Mon, 15 Jan 2018 19:41:47 -0500 Received: from mail-wr0-f195.google.com ([209.85.128.195]:44350 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751279AbeAPAlk (ORCPT ); Mon, 15 Jan 2018 19:41:40 -0500 X-Google-Smtp-Source: ACJfBosxv4Fq5/ulxlQj15Qvv6pMj0CfKz3yl8F91K3dIr54Jw5Ei05V6ndDRKROjbLUTKYJRJrZtQ== Date: Tue, 16 Jan 2018 01:41:28 +0100 From: Ingo Molnar To: Nadav Amit Cc: Dave Hansen , LKML , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , w@1wt.eu, Linus Torvalds Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI Message-ID: <20180116004128.us5uprkzrr5gf4li@gmail.com> References: <20180114201306.3554-1-namit@vmware.com> <57a8fa6b-a1d1-d440-ce13-b1d06d265584@linux.intel.com> <3D823F02-89EF-48D9-913D-5E65391F6F9D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D823F02-89EF-48D9-913D-5E65391F6F9D@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: * Nadav Amit wrote: > > Also, what's the end goal here? Run old 32-bit binaries better? You > > want to weaken the security of the whole implementation to do that? > > Sounds like a bad tradeoff to me. > > As Willy noted in this thread, I think that some users may be interested in > running 32-bit Apache/Nginx/Redis to get the performance back without > sacrificing security. Note that it is a flawed assumption to think that this is possible, as they might in many cases not be getting their performance back: 32-bit binaries for the same general CPU bound computation can easily be 5% slower than 64-bit binaries (as long as the larger cache footprint of 64-bit data doesn't fall out of key caches), but can be up to 30% slower for certain computations. In fact, depending on how kernel heavy the web workload is (for example how much CGI processing versus IO it does, etc.), a 32-bit binary could be distinctly _slower_ than even a PTI-enabled 64-bit binary. So we are trading a 5-15% slowdown (PTI) for another 5-15% slowdown, plus we are losing the soft-SMEP feature on older CPUs that PTI enables, which is a pretty powerful mitigation technique. Yes, I suspect in some (maybe many) cases it would be a speedup, but I really don't like the underlying assumptions and tradeoffs here. (Not that I like any of this whole Meltdown debacle TBH.) Thanks, Ingo