> From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Monday, February 29, 2016 10:21 AM > To: George Spelvin <li...@horizon.com> > > From a quick look, the stuff in the examples was already in the rapl driver. >
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. > If it is that specialized, then it doesn't belong upstream. > 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). 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. 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. Further, keeping msr.ko provides a means for software developers to work with hardware architects on emerging hardware technologies where new MSRs have been added or updated. Removing the ability to access newly added or updated MSRs without having new kernel code would negatively impact these types of development activities being utilized today. > The burden comes when people start complaining about strange issues and we > go and have to get a full MSR dump at the time the explosion happens because > some userspace tool went nuts and scribbled all over them. No one wants to be > on the receiving end of a bug report like this. > This is precisely why the whitelist approach is being proposed. The current version of msr.ko will gladly allow userspace tools with capabilities set to scribble all over them. With whitelists, system admins can turn off capabilities for the apps and limit access to a very small subset of bits of a small subset of MSRs. Marty
