From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751166AbaKAWKP (ORCPT ); Sat, 1 Nov 2014 18:10:15 -0400 Received: from www.linutronix.de ([62.245.132.108]:47629 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750786AbaKAWKN (ORCPT ); Sat, 1 Nov 2014 18:10:13 -0400 Date: Sat, 1 Nov 2014 23:10:02 +0100 (CET) From: Thomas Gleixner To: Andy Lutomirski cc: X86 ML , Peter Zijlstra , Ingo Molnar , "hillf.zj" , Vince Weaver , "linux-kernel@vger.kernel.org" , Paul Mackerras , Kees Cook , Arnaldo Carvalho de Melo , Andrea Arcangeli , Valdis Kletnieks Subject: Re: [PATCH v2 5/8] perf: Add pmu callbacks to track event mapping and unmapping In-Reply-To: Message-ID: References: <266afcba1d1f91ea5501e4e16e94bbbc1a9339b6.1414190806.git.luto@amacapital.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 1 Nov 2014, Andy Lutomirski wrote: > On Nov 1, 2014 1:39 PM, "Thomas Gleixner" wrote: > > On Sat, 1 Nov 2014, Andy Lutomirski wrote: > > > There's plenty of room to tighten up the restrictions further, but > > > this is, I think, a decent first step, and it solves the problem of > > > information leaking into seccomp sandboxes. > > > > In which way? > > All the performance counters were readable without using any syscalls. > That leaks hints as to which events are in use, and it possibly leaks > interesting side channel information. With this series applied, you > need a at least mmap an rdpmc-able event, which most seccomp sandboxes > won't allow. Ok. So you are preventing the seccomp sandboxes to open/mmap a counter. > Unfortunately, rdpmc access to counters can't be controlled > individually, so it's hard to do all that much better than this. Yeah, I know ... Thanks, tglx