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

["Rountree, Barry L." <rountree4@llnl.gov>]

On 2/29/16, 3:41 PM, "Borislav Petkov" <bp@alien8.de> 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.

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


>
>Also, as I hinted at before, you have cases where other drivers
>and modules access the same MSRs as msr.ko and for that you need
>synchronization. Which would then need to be added. But we're going
>to be stuck with this wrong interface already and we then would be
>*extending* that wrong interface. No thanks.

Synchronization wasn't provided by msr.ko and that doesn't appear to
have caused any problems.  If synchronization is a problem, it's easy
enough to remove the offending MSR from the whitelist.

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

>
>> Keeping msr.ko around and adding a whitelist mechanism will provide a
>> safe means for developers to experiment with MSR sets in their to
>> squeeze out performance and power and possibly inform future features
>> of modules like the rapl driver.
>
>This can be done with msr.ko now too.

The security model for msr.ko is all-or-nothing.  That's not a sane choice
for production environments.

Barry Rountree
Center for Applied Scientific Computing
Lawrence Livermore National Laboratory