Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030646AbbDWSg1 (ORCPT ); Thu, 23 Apr 2015 14:36:27 -0400 Received: from mail-ie0-f174.google.com ([209.85.223.174]:33859 "EHLO mail-ie0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030493AbbDWSgX (ORCPT ); Thu, 23 Apr 2015 14:36:23 -0400 MIME-Version: 1.0 In-Reply-To: References: <5538C1C5.7010408@redhat.com> <20150423101840.GC28327@pd.tnic> <5538C8E3.60009@redhat.com> <20150423104401.GF28327@pd.tnic> <20150423171440.GP28327@pd.tnic> Date: Thu, 23 Apr 2015 11:36:22 -0700 X-Google-Sender-Auth: hly4bLUneuTcc-GFM0r4OqlnA10 Message-ID: Subject: Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss From: Linus Torvalds To: Andy Lutomirski Cc: Borislav Petkov , Denys Vlasenko , Denys Vlasenko , Brian Gerst , Steven Rostedt , Oleg Nesterov , Ingo Molnar , "H. Peter Anvin" , 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: 2167 Lines: 49 On Thu, Apr 23, 2015 at 11:24 AM, Andy Lutomirski wrote: > > 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)? So I'm ok with doing it in the sysret path, and just know that we randomly have 0 or __KERNEL_DS in %ss while in kernel mode depending on how we entered it. But I'd like to make sure it is: - documented somewhere (I feel that I understand the problem better now, but three years from now I will have forgotten all the details and be surprised about the 0/__KERNEL_DS issue all over again) And by "documented somewhere" I very much mean _both_ the 0/__KERNEL_DS issue _and_ the odd 'AMD sysret buglet' - I think we should do it for both 32-bit and 64-bit, or at the very least add a comment to the 64-bit path about this - I think the sysret code should also make it clear that this is a CPU buglet That "sysret code should make it clear" coould possibly be just by commenting on it (so that "document it clearly" could be the entire solution), but possibly by even making the fixup be something that uses the instruction rewriting logic so that it is both (a) very explicit as a "these CPU's have a problem" and (b) cheaper on CPU's that don't have the issue. I don't think anybody really cares about a few cycles in the 32-bit compat path on a 64-bit kernel, but the pure 64-bit case we might care about an extra cycle or three. Considering that it apparently _is_ a CPU buglet, I don't think we want to touch the schedule path after all. The odd behavior wrt %ss is kind of confusing, but if we document it and just clarify that all returns to user space fix things up, I guess I don't care. Hmm? Linus -- 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/