On Mon, 29 Feb 2016, Borislav Petkov wrote: > What you want to achieve can be implemented - if it hasn't happened > already - in the already supplied drivers (rapl, x86_energy_perf_policy, > etc). > > Then, instead of filtering access to MSRs, we should not allow any > non-OS controlled access to them. That means, not shipping msr.ko at > all. Why? > > You simply don't want to allow uncontrolled access to MSRs from > userspace. Even to root. It is simply too dangerous to poke at them.
Fully agreed. That said, it would be nice to have a patchset (intended mostly for stable/LTS backporting) that restricts MSR access to a *static* whitelist that allows only the minimal access required by the current crop of general use utilities like powertop, turbostat, etc. We do need to deprecate MSR.ko, but IMHO it would be worth it to take the time to make MSR.ko safer anyway *and backport that to older kernels* because that is going to increase security on a large number of systems that can't just disable MSR.ko without losing functionality right now. Some kconfig control for what is included in the static whitelist (with appropriate defaults) could make the deprecation period mostly painless both for general use distros (that *do* enable MSR.ko) and for HPC deployments... IMHO it would be acceptable to have a more complicated scenario where there is a static "master whitelist", which can be made more strict (i.e. remove access rights) through a soft whitelist managed by userspace (with appropriate capability checks), if there is a real need for that level of control on something we want to deprecate. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
