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: <20160229163144.GA7426@khazad-dum.debian.net>
Date:	Mon, 29 Feb 2016 13:31:44 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Borislav Petkov <bp@...en8.de>
Cc:	"Mcfadden, Marty Jay" <mcfadden8@...l.gov>,
	Ingo Molnar <mingo@...nel.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>,
	"linux@...izon.com" <linux@...izon.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"luto@...nel.org" <luto@...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>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction

On Mon, 29 Feb 2016, Borislav Petkov wrote:
> What you want to achieve can be implemented - if it hasn't happened
> already - in the already supplied drivers (rapl, x86_energy_perf_policy,
> etc).
> 
> Then, instead of filtering access to MSRs, we should not allow any
> non-OS controlled access to them. That means, not shipping msr.ko at
> all. Why?
> 
> You simply don't want to allow uncontrolled access to MSRs from
> userspace. Even to root. It is simply too dangerous to poke at them.

Fully agreed.  That said, it would be nice to have a patchset (intended
mostly for stable/LTS backporting) that restricts MSR access to a *static*
whitelist that allows only the minimal access required by the current crop
of general use utilities like powertop, turbostat, etc.

We do need to deprecate MSR.ko, but IMHO it would be worth it to take the
time to make MSR.ko safer anyway *and backport that to older kernels*
because that is going to increase security on a large number of systems that
can't just disable MSR.ko without losing functionality right now.

Some kconfig control for what is included in the static whitelist (with
appropriate defaults) could make the deprecation period mostly painless both
for general use distros (that *do* enable MSR.ko) and for HPC deployments...

IMHO it would be acceptable to have a more complicated scenario where there
is a static "master whitelist", which can be made more strict (i.e. remove
access rights) through a soft whitelist managed by userspace (with
appropriate capability checks), if there is a real need for that level of
control on something we want to deprecate.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh