Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753018AbbF3MVF (ORCPT ); Tue, 30 Jun 2015 08:21:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39900 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752043AbbF3MU7 (ORCPT ); Tue, 30 Jun 2015 08:20:59 -0400 Message-ID: <559289A7.3040500@redhat.com> Date: Tue, 30 Jun 2015 08:20:55 -0400 From: Prarit Bhargava User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: "H. Peter Anvin" CC: Andy Lutomirski , Ingo Molnar , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , X86 ML , Len Brown , Dasaratharaman Chandramouli , Peter Zijlstra , Borislav Petkov , Andy Lutomirski , Denys Vlasenko , Brian Gerst , Arnaldo Carvalho de Melo , Henrique de Moraes Holschuh , Matt Fleming Subject: Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr References: <1435341131-3279-1-git-send-email-prarit@redhat.com> <20150627083354.GA12834@gmail.com> <20150627083921.GA13074@gmail.com> <559005DD.3070003@redhat.com> <5591A1D3.6010003@zytor.com> In-Reply-To: <5591A1D3.6010003@zytor.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1976 Lines: 56 The MSR exposure seems to be okay with the following statements: - complete read of /dev/cpu/X/msr is bad, whitelist instead - needs to be dependent on either CPU version or reading MSRs for support. IIRC the Intel documentaton on the MSRs indicated that there are ways to check to see if a particular MSR is supported by a processor. That doesn't seem difficult to do IMO. Here are the options that have been discussed in this thread, as well as a third that I'm proposing: 1. Andy's PMU driver suggestion (eventually exposed via sysfs) 2. Standalone driver (LLNL) which exposes values in sysfs (one value per sysfs file) 3. Make /dev/cpu/X/msr readable for those addresses in the whitelist. ie) Allow read access to address for IA32_MPERF, etc. I find exposing MSRs via sysfs difficult to maintain as we move forward. I suppose we could name them according to their MSR names in the Intel documentation, however from a userspace point of view I still find it cumbersome to code that way. Doing this in the existing /dev/ space has the benefit that we wouldn't have to change any userspace code. For those users who did (in some crazy situation) want full read access, they can still do 'setcap' on that particular executable. Using Henrique's list of packages that use /dev/cpu/X/msr, * cpufrequtils * flashrom * i7z * intel-gpu-tools * inteltool * mcelog * msrtool, msr-tools * PAPI (can use msr_safe) * powertop * qemu * slurm-llnl (maybe this can also use msr_safe?) * stressapptest * turbostat * wmlongrun, longrun * x86info * xserver-xorg-video-geode it seems like visiting changes on each of these packages (and the other packages that I'm sure I've missed) will be moderately difficult. Thoughts? P. -- 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/