Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758105AbbDWPss (ORCPT ); Thu, 23 Apr 2015 11:48:48 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:34195 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753459AbbDWPsq (ORCPT ); Thu, 23 Apr 2015 11:48:46 -0400 MIME-Version: 1.0 In-Reply-To: <20150423104401.GF28327@pd.tnic> References: <63da6d778f69fd0f1345d9287f6764d58be519fa.1427482099.git.luto@kernel.org> <5538C1C5.7010408@redhat.com> <20150423101840.GC28327@pd.tnic> <5538C8E3.60009@redhat.com> <20150423104401.GF28327@pd.tnic> From: Andy Lutomirski Date: Thu, 23 Apr 2015 08:48:25 -0700 Message-ID: Subject: Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss To: Borislav Petkov Cc: Denys Vlasenko , Brian Gerst , Steven Rostedt , Oleg Nesterov , Ingo Molnar , "H. Peter Anvin" , Linus Torvalds , Andy Lutomirski , Will Drewry , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Alexei Starovoitov , Linux Kernel Mailing List , Kees Cook , Thomas Gleixner , "linux-tip-commits@vger.kernel.org" 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: 1720 Lines: 48 On Thu, Apr 23, 2015 at 3:44 AM, Borislav Petkov wrote: > On Thu, Apr 23, 2015 at 12:26:43PM +0200, Denys Vlasenko wrote: >> Yes. It loads *selector*. AMD docs say that selector is loaded as you say, >> but *cached descriptor* of SS (which is a different entity) is not modified. >> >> If *cached descriptor* is invalid, in 32-bit mode stack ops >> will fail. (In 64-bit mode, CPU doesn't do those checks). > > So how can that happen with wine? Something's changing the cached > descriptor and only the write to %ss reloads it with the correct value? > I bet that the actual crashing task is a red herring. How about this theory: Some *other* Wine program is running either in 16-bit mode or in 32-bit mode with the stack limit != 0xffffffff. We take an interrupt and, as an optimization, the CPU doesn't reset the cached SS limit and/or attributes (what would it reload them to, anyway?). Now we context switch to a syscall issues by the dying task and do sysretl, and we accidentally land back in userspace in segmented mode. If this theory is right, it explains why we only see this on Wine. It also means we may have an info leak on 64-bit syscalls, too (see other thread). A test for this would be to run syscalls in a loop in a native 32-bit process while running dosbox or something like that. --Andy > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > -- -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/