lkml.org 
[lkml]   [2016]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction
On Feb 28, 2016 6:55 PM, "Mcfadden, Marty Jay" <mcfadden8@llnl.gov> wrote:
>
> > On Sun, Feb 28, 2016, Borislav Petkov <bp@alien8.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

\
 
 \ /
  Last update: 2016-02-29 18:41    [W:2.197 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site