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]

Date:	Mon, 29 Feb 2016 09:17:41 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Marty McFadden <mcfadden8@...l.gov>
Cc:	Ingo Molnar <mingo@...hat.com>, Brian Gerst <brgerst@...il.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	"dyoung@...hat.com" <dyoung@...hat.com>,
	Jiri Olsa <jolsa@...hat.com>,
	"yu.c.chen@...el.com" <yu.c.chen@...el.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"hpa@...or.com" <hpa@...or.com>, "pavel@....cz" <pavel@....cz>,
	"andriy.shevchenko@...ux.intel.com" 
	<andriy.shevchenko@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"linux@...izon.com" <linux@...izon.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"bp@...e.de" <bp@...e.de>
Subject: RE: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction

On Feb 28, 2016 6:55 PM, "Mcfadden, Marty Jay" <mcfadden8@...l.gov> wrote:
>
> > On Sun, Feb 28, 2016, Borislav Petkov <bp@...en8.de> wrote:
> >
> > Can we have some concrete examples for that please?
> >
>
> Our environment allows users to have exclusive access to some
> number of compute nodes for a limited time.  Bit-level control of
> MSRs is required when a user might gain root or, more commonly,
> interfere with subsequent jobs run by other users.
>
> The canonical examples for bitwise control are
> MSR_PKG_POWER_LIMIT and MSR_DRAM_POWER_LIMIT.  We
> want to provider user space control over power bounds, but if
> the lock bit is set the power bound cannot be changed without
> rebooting.  As setting very low power bounds can slow
> performance by a factor of 4x or worse, leaving the lock bit
> writable allows a crude denial-of-service attack.
>
> A second use case for bitwise control is IA32_MISC_ENABLE.  This
> MSR controls a wide variety of processor functionality, some of
> which is benign ("Performance Energy Bias Hint") and some that
> might not be ("Automatic Thermal Control Circuit Enable").  Rather
> than do a formal security review of the dozen features controlled
> by this MSR, we'd like to take the simpler step of allowing writes
> to only what we know is safe.  Note that bit "Enhanced Intel
> SpeedStep Technology Select Lock" is a lock bit.

ISTM you should either write a kernel driver that exposes a real
interface for these controls or a userspace daemon that offers this as
a service.

>
> Thanks,
>
> Marty McFadden