Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753947AbcKUSA6 (ORCPT ); Mon, 21 Nov 2016 13:00:58 -0500 Received: from mail-oi0-f68.google.com ([209.85.218.68]:33586 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752264AbcKUSA5 (ORCPT ); Mon, 21 Nov 2016 13:00:57 -0500 MIME-Version: 1.0 In-Reply-To: <20161121071342.GA16999@gmail.com> References: <20161121071342.GA16999@gmail.com> From: Linus Torvalds Date: Mon, 21 Nov 2016 10:00:56 -0800 X-Google-Sender-Auth: 7cOkKqTjC7f0voB6RVD8mv9aXLs Message-ID: Subject: Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot? To: Ingo Molnar Cc: Andy Lutomirski , Brian Gerst , Andy Lutomirski , tedheadster@gmail.com, "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: 855 Lines: 23 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. Let's not add complexity to entry. Make the structure actually reflect reality instead. Linus