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: <1A7043D5F58CCB44A599DFD55ED4C948468A477B@fmsmsx115.amr.corp.intel.com>
Date:	Wed, 1 Jul 2015 16:38:37 +0000
From:	"Brown, Len" <len.brown@...el.com>
To:	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	Prarit Bhargava <prarit@...hat.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
	"Chandramouli, Dasaratharaman" 
	<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>
Subject: RE: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr

> This driver only knows how to handle counters, though.  I'm not sure
> whether all of the MSRs that turbostat needs are counters.

turbostat --debug
dumps a lot of configuration MSRs that are not counters.

"--debug" is not an obscure option, it is the only way that
the turbostat is used by advanced users, since it shows not just
how fast a system is running, but explains why.

turbostat -M or -C 'address'
will dump an arbitrary MSR at offset 'address' in hex or counter format.

This allows somebody to use yesterday's turbostat application
to dump an MSR that didn't exist when the application was written.
(and since the MSR driver doesn't have specific MSR addresses
 hard-coded into it, that is permitted)

> I knew that turbostat only did MSR reads

FYI, There have been proposals for turbostat to do MSR writes,
and I've resisted them because I like that multiple turbostats
can run at different intervals and even different users,
and not interfere with each other.  One of the proposals
was due to a short counter that tends to over-flow.  That,
I think would be better done in a central place in the kernel,
though it shouldn't poll unless it is actually being used.
The other is to be able to fix configuration bits that
are recognized to be incorrect or non-optimal. 

BTW. I've had a discussion w/ LLNL about their needs,
both for security and performance.  For security, as concluded
by this thread, a white list is the only way to go.
I'm thinking a bit-vector of allowed MSR offsets...
For performance, they absolutely can not afford a system call
for every single MSR access.  Here an ioctl to have the
msr driver perform a vector of accesses in a single system
call seems the way to go.  I can prototype both of these
using turbostat as the customer.

-Len