Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754747Ab3JBROP (ORCPT ); Wed, 2 Oct 2013 13:14:15 -0400 Received: from mail-ie0-f181.google.com ([209.85.223.181]:59358 "EHLO mail-ie0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753623Ab3JBRON (ORCPT ); Wed, 2 Oct 2013 13:14:13 -0400 MIME-Version: 1.0 In-Reply-To: <20131002133759.GH28601@twins.programming.kicks-ass.net> References: <20130930165420.GI3081@twins.programming.kicks-ass.net> <20131002112316.GP3081@twins.programming.kicks-ass.net> <20131002115826.GM26785@twins.programming.kicks-ass.net> <20131002123953.GB27811@gmail.com> <20131002124610.GD28601@twins.programming.kicks-ass.net> <20131002130143.GF28601@twins.programming.kicks-ass.net> <20131002133759.GH28601@twins.programming.kicks-ass.net> Date: Wed, 2 Oct 2013 10:14:11 -0700 X-Google-Sender-Auth: KbzXUxBwV22n2i3AByjzL8H_dJs Message-ID: Subject: Re: [RFC] perf: mmap2 not covering VM_CLONE regions From: Kees Cook To: Peter Zijlstra Cc: Stephane Eranian , Ingo Molnar , LKML , "mingo@elte.hu" , "ak@linux.intel.com" , Arnaldo Carvalho de Melo , David Ahern , Jiri Olsa , Hugh Dickins , Linus Torvalds , Andrew Morton Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2750 Lines: 58 On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra wrote: > On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote: >> On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra wrote: >> > On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote: >> >> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra wrote: >> >> > On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote: >> >> >> - then there are timing attacks, and someone having access to a PMU >> >> >> context and who can trigger this SHA1 computation arbitrarily in task >> >> >> local context can run very accurate and low noise timing attacks... >> >> >> >> >> >> I don't think the kernel's sha_transform() is hardened against timing >> >> >> attacks, it's performance optimized so it has variable execution time >> >> >> highly dependent on plaintext input - which leaks information about the >> >> >> plaintext. >> >> > >> >> > Typical user doesn't have enough priv to profile kernel space; once you >> >> > do you also have enough priv to see kernel addresses outright (ie. >> >> > kallsyms etc..). >> >> > >> >> I was going to say just that. But that's not the default, paranoid level >> >> is at 1 by default and not 2. So I supposedly can still do: >> >> >> >> $ perf record -e cycles ...... >> >> >> >> In per-thread mode and collect kernel level addresses. >> > >> > Oh right you are.. so yes that's a very viable avenue. >> >> You mean simply encoding the vma->vm_mm as the ino number, for instance. > > Nah.. I think Kees would very much shoot us on the spot for doing that. > But with the paranoid level defaulting to 1 the PMU attack on the kernel > SHA implenentation is feasible. We already have other kernel address leaks (e.g. heap addresses via INET_DIAG), and I'd like to avoid adding more. It'd be nice if there was a common way to uniquely mask these values that are really just "handles". We could use it both here and in the network code. Would it be possible to just have a "regular" incrementing handle, like fd, or are we talking about doing that map for all VMAs, which would make that mapping unfeasible due to storage needs? On the other hand, trying to hide kernel addresses from root is no easy task, especially given that while kptr_restrict has a "2" level, dmesg_restrict does not. Are these kernel-address-leaking perf modes already limited to a specific POSIX capability? -Kees -- Kees Cook Chrome OS Security -- 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/