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:	29 Feb 2016 12:53:18 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	bp@...en8.de, mcfadden8@...l.gov
Cc:	a.p.zijlstra@...llo.nl, acme@...radead.org, ak@...ux.intel.com,
	andriy.shevchenko@...ux.intel.com, brgerst@...il.com,
	dan.j.williams@...el.com, dyoung@...hat.com, hpa@...or.com,
	jolsa@...hat.com, linux-kernel@...r.kernel.org, linux@...izon.com,
	luto@...nel.org, mingo@...nel.org, mingo@...hat.com, pavel@....cz,
	tglx@...utronix.de, viro@...iv.linux.org.uk, x86@...nel.org,
	yu.c.chen@...el.com
Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction

Borislav Petkov <bp@...en8.de> wrote:
> 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.

I worry that this is this too ambitious a goal.  Who is volunteering
to actually do this?

It takes quite a while to find a good OS-level abstraction (remember
wakelocks?), and MSRs are the CPU architect's equivalent of ioctls.
So they're a bit of a mess, and there will keep being new ones.

I agree with you about anything that's going to see widespread use, but
for specialized (apparently mostly HPC) use where the application really
is heavily optimized for specific CPU models, perhaps dangerous-but-simple
is good enough?

The proposed interface is simple and imposes very little maintenance
burden on the kernel.  My main objection is that it's yet another
special-case permission system.  Are we *sure* we'll never want to have
to classes of users with different access rights?