Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction

[Andy Lutomirski]

On Mar 1, 2016 11:01 AM, "Rountree, Barry L." <rountree4@xxxxxxxx> wrote:
>
>
>
> On 2/29/16, 3:41 PM, "Borislav Petkov" <bp@xxxxxxxxx> wrote:
>
> >On Mon, Feb 29, 2016 at 10:35:12PM +0000, Mcfadden, Marty Jay wrote:
> >> The examples provided were to address why bit-level access granularity
> >> was needed.  They were not intended to be, nor are they, a
> >>comprehensive list
> >> of scenarios.
> >
> >So which scenarios cannot be satisfied by proper implementation of
> >userspace APIs (sysfs, procfs, etc) and direct access to MSRs is the
> >only way?
>
> All of them can *eventually* be implemented with userspace APIs.  But that
> process can take years.  We had an early version of msr-safe allowing
> whitelisted RAPL access in 2012.  I don't think a RAPL driver hit
> linux mainline until 2015.
>
> One way of getting more resources into "proper implementations" is by
> showing how usefulness of the userspace + msr-safe implementation.

How about a userspace + msr.ko implementation with no kernel changes
whatsoever?  We're not talking about a lot of code here.

>
> >
> >> What is being proposed is to make msr.ko better with a whitelist which
> >> does not allow access to any MSRs be default unless you are root or
> >> are a user with the appropriate capability (which is how it works
> >> today).
> >
> >That doesn't protect you from mistakenly configuring the wrong mask, as
> >root. A well-defined userspace interface does.
>
> No userspace interface will protect you from mistaken configurations as
> root.  You can mitigate the mistakes by making the defaults sane (the
> default here is no userspace access at all) and by making inadvertent
> errors unlikely (it's unlikely that root will edit the whitelist by
> mistake; if it happens it still needs to be echoed into the whilelist
> file; any invalid line invalidates the entire whitelist and puts the
> system back into no-userspace-access mode).

Then configure the existing code correctly.

Step 1: Only root gets access to /dev/msr

Step 2: Your semi-privileged users get access to a user daemon or CUSE
device or whatever that implements your security policy

Step 3: Remember not to complain upstream if your MSR write breaks things.

Which reminds me: we should probably create a rather limited (maybe
even empty) list of MSRs that may be written via /dev/msr without
tainting the kernel.


> >
> >> System Administrators can then selectively add entries to the whitelist
> >> to allow userspace applications access to specified bits of specific
> >>MSRs
> >> of interest.  This can all be done on emerging hardware before new
> >> updates or interfaces are added to the kernel.
> >
> >Emerging hardware uses specialized hw bringup software - not the
> >upstream kernel. Or it is a heavily patched beyond recognition ancient
> >upstream kernel. And to that kernel people can do whatever they want.
>
> Absolutely.  The problem we're trying to solve is that msr.ko shouldn't
> be used on production machines.  However, our users want the capabilities
> provided by new MSRs well before they show up in mainline.  msr-safe is
> the best solution we've come up with.  We do far less kernel patching
> (which our security folks really appreciate), users can't inadvertently
> trash the machine (which our sysadmins appreciate) and our users get
> access to new processor functionality on production machines.

Why exactly can't msr.ko be used in production?  Remember, you're
already claiming that you believe that certain MSRs are okay to poke
behind the kernel's back.

--Andy