Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966416AbbDWQFL (ORCPT ); Thu, 23 Apr 2015 12:05:11 -0400 Received: from mail-ig0-f169.google.com ([209.85.213.169]:37093 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966164AbbDWQFI (ORCPT ); Thu, 23 Apr 2015 12:05:08 -0400 MIME-Version: 1.0 In-Reply-To: References: <1429792491-5978-1-git-send-email-dvlasenk@redhat.com> Date: Thu, 23 Apr 2015 09:05:07 -0700 X-Google-Sender-Auth: v4oWnz6MZFoDjJzLE4AkT1WojRI Message-ID: Subject: Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary From: Linus Torvalds To: Andy Lutomirski Cc: Denys Vlasenko , Ingo Molnar , Brian Gerst , Steven Rostedt , Borislav Petkov , "H. Peter Anvin" , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , "the arch/x86 maintainers" , Linux Kernel Mailing List 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: 2245 Lines: 47 On Thu, Apr 23, 2015 at 8:50 AM, Andy Lutomirski wrote: > On Thu, Apr 23, 2015 at 8:22 AM, Linus Torvalds >> >> It is a bit scary to me that apparently we leak %ss values between >> processes, so that while we run in the kernel we can randomly have the >> ss descriptor either be 0 or __KERNEL_DS. That sounds like an >> information leak to me, even in 64-bit mode. The value of %ss may not >> *matter* in 64-bit mode, but leaking that difference between processes >> sounds nasty. I can't offhand thing of any way to actually read the >> present bit in the cached descriptor (I was thinking something like >> the "LSL" instruction, but that takes a new segment selector, not the >> segment itself), but it just smells odd to me. > > How about, in 64-bit code: syscall; long jump to a 32-bit cs; mov with > ss override (or push or pop). Yeah. That sounds likely. Something that doesn't reload SS, but gets us to a point where the present bit matters. So basically it would allow an "attacker" to see whether it got scheduled away and an interrupt happened elsewhere. Which doesn't exactly sound like much of an information leak ("just read /proc/interrupts instead"), so I guess from a security standpoint this really doesn't matter. But I could see how it could break odd code. So I think even the 64-bit sysret path has this problem, it's just that any *sane* 64-bit user will never care. But insane ones could. And presumably Intel doesn't have this problem, because Intel's sysret properly loads the whole cached ss descriptor (that's certainly what the Intel documentation says: "However, the CS and SS descriptor caches are not loaded from the descriptors (in GDT or LDT) referenced by those selectors. Instead, the descriptor caches are loaded with fixed values"). So it sounds very much like an AMD bug/misfeature. Because sysret *should* reset the descriptor cache. Do we know whether this affects *all* AMD CPU's or just a subset? 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/