Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755798AbcKVRah (ORCPT ); Tue, 22 Nov 2016 12:30:37 -0500 Received: from mail-ua0-f180.google.com ([209.85.217.180]:35432 "EHLO mail-ua0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbcKVRae (ORCPT ); Tue, 22 Nov 2016 12:30:34 -0500 MIME-Version: 1.0 In-Reply-To: <20161122083043.GA16081@gmail.com> References: <20161121071342.GA16999@gmail.com> <20161122083043.GA16081@gmail.com> From: Andy Lutomirski Date: Tue, 22 Nov 2016 09:30:12 -0800 Message-ID: Subject: Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot? To: Ingo Molnar Cc: Linus Torvalds , Brian Gerst , Andy Lutomirski , Matthew Whitehead , "H. Peter Anvin" , George Spelvin , "linux-kernel@vger.kernel.org" , X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2483 Lines: 63 On Tue, Nov 22, 2016 at 12:30 AM, Ingo Molnar wrote: > > * 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. The SDM says: If the source operand is an immediate of size less than the operand size, a sign-extended value is pushed on the stack. If the source operand is a segment register (16 bits) and the operand size is 64-bits, a zero- extended value is pushed on the stack; if the operand size is 32-bits, either a zero-extended value is pushed on the stack or the segment selector is written on the stack using a 16-bit move. For the last case, all recent Core and Atom processors perform a 16-bit move, leaving the upper portion of the stack location unmodified. This makes me think that even new processors are quirky. --Andy