linux-kernel - Re: [RFC PATCH] x86: Move away from /dev/cpu/*/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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 15 Jun 2016 19:39:26 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Len Brown <lenb@...nel.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Thomas Renninger <trenn@...e.com>,
	Kan Liang <kan.liang@...el.com>,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Len Brown <len.brown@...el.com>,
	Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [RFC PATCH] x86: Move away from /dev/cpu/*/msr

On Wed, Jun 15, 2016 at 01:21:01PM -0400, Len Brown wrote:
> The API -- the name -- must be clear about what MSR it talks to.

Didn't I say that?!

"Surely we can make the new interface work too - perhaps add a new sysfs
file for the new thing."

> I suggest that the name exactly match the name of the actual MSR,
> because you are about to need a 2nd one with a name so close
> that it will otherwise be ambiguous.

So from looking at IA32_HWP_REQUEST, it sounds like you'd need a whole
new dir:

hwp_req
|-> package_control
|-> energy_perf_pref
|-> ...
|-> min_perf

and both interfaces will be visible only when the CPUID bit is set.

I.e., for the energy_policy_pref_hint, I'm checking X86_FEATURE_EPB and
I'm sure the HWP ones have CPUID bits too.

> Again, I support your direction.  I'm not trying to work against it,
> I'm trying to tell you that you are just scratching the surface
> and there will be more steps to complete the task -- because
> there are more MSRs.

Oh, I know that. That's why this is a first RFC, to poke at people.

Also, I'm looking at the WRMSR use cases first. The reading can be taken
care of later.

> Your new API doesn't exist on the installed base, and so the old
> /dev/msr method must be available to the installed base. Sure, in the
> future, when the new API is available, we can update the utility to
> use it going forward.

Well, since the utility is part of tools/, it goes with the kernel
version. Just like perf.

Or are you dying to be able to use new tool on old kernels?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.