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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 1 Mar 2016 18:29:59 +0000
From:	"Rountree, Barry L." <rountree4@...l.gov>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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>,
	"Mcfadden, Marty Jay" <mcfadden8@...l.gov>,
	"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>,
	Thomas Gleixner <tglx@...utronix.de>,
	Travis Gummels <tgummels@...hat.com>,
	"Eastep, Jonathan M" <jonathan.m.eastep@...el.com>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"prarit@...hat.com" <prarit@...hat.com>
Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction

On 3/1/16, 12:02 AM, "Thomas Gleixner" <tglx@...utronix.de> wrote:

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

Here's how kernel development is done is secure facilities.

Any new code going into the kernel gets an extensive (and expensive)
security
review.  It has to be right the first time.  We don't have the luxury of
iterating back and forth several times between the testbed machines and
the 
production floor.

Because of this we keep as much functionality as possible outside of the
kernel.  Most of the time, all we really need the kernel to do is read and
write MSRs (quickly).

And because kernel-driver-per-MSR-group leads to lots of new kernel
drivers,
we like to refactor when we can.  Most new functionality can be captured
by having a single driver that just reads and writes the MSRs we need.

So now we have one kernel module to review instead of dozens.  When we
want to move a new processor feature to the production floor, the security
review is focused on what the MSR does.  The kernel code itself is
unchanged.
If the new MSR is deemed safe enough, the only thing that needs to change
on 
production machines is a new entry in the whitelist.  And if need be, that
whitelist can extend to individual bits.

You're absolutely right that developers don't need this functionality.
Users do.  msr-safe allows users to get access to benign MSRs that either
don't have kernel interfaces yet or whose kernel interfaces don't meet
their specialized needs.  And we can provide this access on production
machines without risking inadvertent or malicious scribbling on non-benign
MSRs.  And we can do this with one simple, straightforward kernel module.

If you have a better way of solving this problem, I'd love to hear it.

>
>Thanks,
>
>        tglx

Barry Rountree
Center for Applied Scientific Computing
Lawrence Livermore National Laboratory

>