Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755669AbcKVIas (ORCPT ); Tue, 22 Nov 2016 03:30:48 -0500 Received: from mail-wj0-f195.google.com ([209.85.210.195]:34716 "EHLO mail-wj0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755502AbcKVIar (ORCPT ); Tue, 22 Nov 2016 03:30:47 -0500 Date: Tue, 22 Nov 2016 09:30:43 +0100 From: Ingo Molnar To: Linus Torvalds Cc: Andy Lutomirski , Brian Gerst , Andy Lutomirski , tedheadster@gmail.com, "H. Peter Anvin" , George Spelvin , "linux-kernel@vger.kernel.org" , X86 ML Subject: Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot? Message-ID: <20161122083043.GA16081@gmail.com> References: <20161121071342.GA16999@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1754 Lines: 49 * Linus Torvalds wrote: > On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar wrote: > > > > So I have applied your fix that addresses the worst fallout directly: > > > > fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in early_fixup_exception() > > > > ... but otherwise we might be better off zeroing out the high bits of segment > > registers stored on the stack, in all entry code pathways > > Ugh. > > I'd much rather we go back to just making the "cs" entry explicitly > 16-bit, and have a separate padding entry, the way we used to long > long ago. > > Or just rename it to something that you're not supposed to access > directly, and a helper accessor function that masks off the high bits. > > The entry code-paths are *much* more critical than any of the few user > codepaths. Absolutely, no arguments about that! > [...] Let's not add complexity to entry. Make the structure actually reflect > reality instead. So I have no problems at all with your suggestion either. I am still trying to semi-defend my suggestion as well, because if we do what I suggested: > > [...] so that the function call is patched out on modern CPUs. then it's essentially an opt-in quirk for really old CPUs and won't impact new CPUs, other than a single NOP for the patched out bits - and not even that on kernel builds with M686 or later or so ... I.e. the quirk essentially implements what new CPUs do (in C), and then all remaining code can just assume that all data is properly initialized/zeroed like on new CPUs and the effects of the quirk does not spread to data structures and code that handles and copies around those data structures - unless I'm missing something. Thanks, Ingo