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: <20160229145859.GA3724@pd.tnic>
Date:	Mon, 29 Feb 2016 15:58:59 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	"Mcfadden, Marty Jay" <mcfadden8@...l.gov>
Cc:	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, Feb 29, 2016 at 02:55:43AM +0000, Mcfadden, Marty Jay wrote:
> 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.

And this all can't be done with the RAPL driver
drivers/powercap/intel_rapl.c?

> 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")

So SDM has IA32_ENERGY_PERF_BIAS (0x1b0) listed for that. I.e., the bits
[3:0] with which you can select between 0 - highest perf and 15 max
energy saving.

That's implemented in x86_energy_perf_policy(8).

And the control bit is in MSR_MISC_PWR_MGMT(0x1aa)[1].

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

If people want to shoot themselves in the foot, I don't think you can
stop them.

Ok, so here's what I think:

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.

What should be done, instead, is implement all functionality you need in
the respective drivers with proper error and input sanity-checking done
by the OS. Also, OS has other agents poking at them so it should be the
arbiter controlling access and so on.

IMNSVHO.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.