On Feb 28, 2016 6:55 PM, "Mcfadden, Marty Jay" <mcfadd...@llnl.gov> wrote:
>
> > On Sun, Feb 28, 2016, Borislav Petkov <b...@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
