linux-kernel - Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction

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:	Tue, 1 Mar 2016 00:41:25 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	"Mcfadden, Marty Jay" <mcfadden8@...l.gov>
Cc:	George Spelvin <linux@...izon.com>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"acme@...radead.org" <acme@...radead.org>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"andriy.shevchenko@...ux.intel.com" 
	<andriy.shevchenko@...ux.intel.com>,
	"brgerst@...il.com" <brgerst@...il.com>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	"dyoung@...hat.com" <dyoung@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"jolsa@...hat.com" <jolsa@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"luto@...nel.org" <luto@...nel.org>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"pavel@....cz" <pavel@....cz>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"x86@...nel.org" <x86@...nel.org>,
	"yu.c.chen@...el.com" <yu.c.chen@...el.com>
Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction

On Mon, Feb 29, 2016 at 10:35:12PM +0000, Mcfadden, Marty Jay wrote:
> The examples provided were to address why bit-level access granularity
> was needed.  They were not intended to be, nor are they, a comprehensive list
> of scenarios.

So which scenarios cannot be satisfied by proper implementation of
userspace APIs (sysfs, procfs, etc) and direct access to MSRs is the
only way?

> What is being proposed is to make msr.ko better with a whitelist which
> does not allow access to any MSRs be default unless you are root or
> are a user with the appropriate capability (which is how it works
> today).

That doesn't protect you from mistakenly configuring the wrong mask, as
root. A well-defined userspace interface does.

Also, as I hinted at before, you have cases where other drivers
and modules access the same MSRs as msr.ko and for that you need
synchronization. Which would then need to be added. But we're going
to be stuck with this wrong interface already and we then would be
*extending* that wrong interface. No thanks.

> System Administrators can then selectively add entries to the whitelist
> to allow userspace applications access to specified bits of specific MSRs
> of interest.  This can all be done on emerging hardware before new
> updates or interfaces are added to the kernel.

Emerging hardware uses specialized hw bringup software - not the
upstream kernel. Or it is a heavily patched beyond recognition ancient
upstream kernel. And to that kernel people can do whatever they want.

> Keeping msr.ko around and adding a whitelist mechanism will provide a
> safe means for developers to experiment with MSR sets in their to
> squeeze out performance and power and possibly inform future features
> of modules like the rapl driver.

This can be done with msr.ko now too.

So no one is removing msr.ko. I'm saying extending it is the wrong
approach. msr.ko is a simple debugging module. Nothing more. Everything
else which is going to be user-visible and widely used, needs to be safe
and clean. Exposing MSRs directly is not. It might be useful for some
niche HPC use cases but is not nearly clean, safe and generic enough for
a userspace API which we will have to support forever.

And the fact that a bunch of tools are already using it is wrong. They
shouldn't. They should use proper, safe user APIs and not poke at MSRs
directly.

-- 
Regards/Gruss,
    Boris.

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