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]

Message-ID: <AEA6FC45760E2A42897809E8E402EA1E0F2CA586@PRDEXMBX-02.the-lab.llnl.gov>
Date:	Mon, 29 Feb 2016 22:35:12 +0000
From:	"Mcfadden, Marty Jay" <mcfadden8@...l.gov>
To:	Borislav Petkov <bp@...en8.de>, George Spelvin <linux@...izon.com>
CC:	"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

> From: Borislav Petkov [mailto:bp@...en8.de]
> Sent: Monday, February 29, 2016 10:21 AM
> To: George Spelvin <linux@...izon.com>
> 
> From a quick look, the stuff in the examples was already in the rapl driver.
>

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.

> If it is that specialized, then it doesn't belong upstream.
>

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).

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.

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.  

Further, keeping msr.ko provides a means for software developers to work
with hardware architects on emerging hardware technologies where new
MSRs have been added or updated.

Removing the ability to access newly added or updated MSRs without having
new kernel code would negatively impact these types of development activities
being utilized today.

> The burden comes when people start complaining about strange issues and we
> go and have to get a full MSR dump at the time the explosion happens because
> some userspace tool went nuts and scribbled all over them. No one wants to be
> on the receiving end of a bug report like this.
> 

This is precisely why the whitelist approach is being proposed.  The current version
of msr.ko will gladly allow userspace tools with capabilities set to scribble all over
them.  With whitelists, system admins can turn off capabilities for the apps and
limit access to a very small subset of bits of a small subset of MSRs.

Marty