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: <alpine.DEB.2.11.1603010849550.3638@nanos>
Date:	Tue, 1 Mar 2016 09:02:59 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Mcfadden, Marty Jay" <mcfadden8@...l.gov>
cc:	Borislav Petkov <bp@...en8.de>, 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>,
	"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, 29 Feb 2016, Mcfadden, Marty Jay wrote:
> 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.

We don't need any of this, really.

Developers who play with experimental or emerging technologies hardly need
that whitelist stuff. They better know what they are doing.

For normal production use we want proper interfaces/drivers for the
technologies which should be made accessible to applications. msr.ko should
not be available on any production machine at all.

Your whitelist filter is just a sloppy hack to foster bad practices. Your
arguments about emerging technologies etc. are just trying to lull us into
accepting your wonderful hackery, so that you can continue to use MSRs in
production environments while pretending that you provide a reasonable amount
of security and sanity around it. Nice try, but it doesn't work...

Thanks,

	tglx