Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030526AbbDWSYk (ORCPT ); Thu, 23 Apr 2015 14:24:40 -0400 Received: from mail-la0-f42.google.com ([209.85.215.42]:33164 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966526AbbDWSYg (ORCPT ); Thu, 23 Apr 2015 14:24:36 -0400 MIME-Version: 1.0 In-Reply-To: <20150423171440.GP28327@pd.tnic> References: <5538C1C5.7010408@redhat.com> <20150423101840.GC28327@pd.tnic> <5538C8E3.60009@redhat.com> <20150423104401.GF28327@pd.tnic> <20150423171440.GP28327@pd.tnic> From: Andy Lutomirski Date: Thu, 23 Apr 2015 11:24:14 -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 , 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: 1848 Lines: 46 On Thu, Apr 23, 2015 at 10:14 AM, Borislav Petkov wrote: > On Thu, Apr 23, 2015 at 09:50:17AM -0700, Andy Lutomirski wrote: >> On Thu, Apr 23, 2015 at 9:41 AM, Denys Vlasenko >> wrote: >> > An alternative fix would be, if we decided to schedule >> > in an interrupt, check %ss for zero and reload it >> > with __KERNEL_DS before schedule. >> >> For anyone who has the right hardware (not me!), a possible reproducer is here: >> >> https://git.kernel.org/cgit/linux/kernel/git/luto/misc-tests.git/ >> >> make && taskset -c 0 ./sysret_ss_attrs_32 > > [ 195.438441] traps: sysret_ss_attrs[1745] trap stack segment ip:f77dab87 sp:ffdf0b70 error:0 > [ 196.831952] traps: sysret_ss_attrs[1748] trap stack segment ip:f7786b87 sp:fffc0810 error:0 > > Ran it twice. That nails it. We really do leak segment limits to other tasks on AMD chips. I see at least two questions we should answer before fixing this: 1. Do we consider this to be enough of a security issue that we want to fix it for 64-bit userspace as well? 2. Do we fix it at sysret time (at the cost of an ss read even in the best case on AMD chips) or at context switch time (with the risk of more ss writes than necessary)? I slightly favor fixing it at sysret time for both the 32-bit and 64-bit paths., but I'm not really convinced. Regardless, I'd rather fix this in the kernel than the vdso. I see no reason at all that we should ever return to 32-bit userspace with a corrupt SS cached descriptor. (OK, tiny lie. The vdso approach avoids a nop somewhere on Intel CPUs. Big deal.) --Andy -- 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/