linux-kernel - Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <559289A7.3040500@redhat.com>
Date:	Tue, 30 Jun 2015 08:20:55 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
	Len Brown <len.brown@...el.com>,
	Dasaratharaman Chandramouli 
	<dasaratharaman.chandramouli@...el.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Brian Gerst <brgerst@...il.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/