Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 29 Feb 2016 09:17:41 -0800 | Subject | RE: [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
| |