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]
Message-ID: <D2FB1410.55ABE%rountree4@llnl.gov>
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

>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ