Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030729AbbDWTVS (ORCPT ); Thu, 23 Apr 2015 15:21:18 -0400 Received: from mail-la0-f51.google.com ([209.85.215.51]:36204 "EHLO mail-la0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030434AbbDWTVQ convert rfc822-to-8bit (ORCPT ); Thu, 23 Apr 2015 15:21:16 -0400 MIME-Version: 1.0 In-Reply-To: <20150423185202.GQ28327@pd.tnic> References: <5538C1C5.7010408@redhat.com> <20150423101840.GC28327@pd.tnic> <5538C8E3.60009@redhat.com> <20150423104401.GF28327@pd.tnic> <20150423171440.GP28327@pd.tnic> <20150423185202.GQ28327@pd.tnic> From: Andy Lutomirski Date: Thu, 23 Apr 2015 12:20:54 -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 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2523 Lines: 91 On Thu, Apr 23, 2015 at 11:52 AM, Borislav Petkov wrote: > On Thu, Apr 23, 2015 at 11:24:14AM -0700, Andy Lutomirski wrote: >> 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: > > Ok, WTF is going on?! Even this trivial test case causes a Bus Error: > > --- > static unsigned short GDT3(int idx) > { > return (idx << 3) | 3; > } > > static void *threadproc(void *ctx) > { > printf("Hello world\n"); > return NULL; > } > > int main() > { > pthread_t thread; > if (pthread_create(&thread, 0, threadproc, 0) != 0) > err(1, "pthread_create"); > > while (1) { > usleep(1); > } > > return 0; > } > --- > > $ make sysret_ss_attrs_32 > gcc -m32 -o sysret_ss_attrs_32 -O2 -g -std=gnu99 -pthread -Wall sysret_ss_attrs.c -lrt -ldl > sysret_ss_attrs.c:23:23: warning: ‘GDT3’ defined but not used [-Wunused-function] > static unsigned short GDT3(int idx) > ^ > $ taskset -c 0 ./sysret_ss_attrs_32 > Hello world > Bus error > > in dmesg: > > [ 583.389368] traps: sysret_ss_attrs[2135] trap stack segment ip:f7784b87 sp:ffb640c0 error:0 > > This is insane. > >> 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. > > Yeah, a "call amd_fixup_ss" which gets NOPped out on Intel with > alternatives sounds nice and clean to me. > > Pending we have an explanation WTH is going on... Huh, what? Maybe interrupt delivery on AMD CPUs actually blows away the descriptor cache completely. On VMX, at least, it's possible to read the descriptor cache directly. I wonder whether the KVM SVM code could be instrumented to do something similar. --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/