Messages in this thread | | | From | "Rountree, Barry L." <> | Subject | Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction | Date | Tue, 1 Mar 2016 18:29:59 +0000 |
| |
On 3/1/16, 12:02 AM, "Thomas Gleixner" <tglx@linutronix.de> wrote:
> >Your whitelist filter is just a sloppy hack to foster bad practices. Your >arguments about emerging technologies etc. are just trying to lull us into >accepting your wonderful hackery, so that you can continue to use MSRs in >production environments while pretending that you provide a reasonable >amount >of security and sanity around it. Nice try, but it doesn't work...
Here's how kernel development is done is secure facilities.
Any new code going into the kernel gets an extensive (and expensive) security review. It has to be right the first time. We don't have the luxury of iterating back and forth several times between the testbed machines and the production floor.
Because of this we keep as much functionality as possible outside of the kernel. Most of the time, all we really need the kernel to do is read and write MSRs (quickly).
And because kernel-driver-per-MSR-group leads to lots of new kernel drivers, we like to refactor when we can. Most new functionality can be captured by having a single driver that just reads and writes the MSRs we need.
So now we have one kernel module to review instead of dozens. When we want to move a new processor feature to the production floor, the security review is focused on what the MSR does. The kernel code itself is unchanged. If the new MSR is deemed safe enough, the only thing that needs to change on production machines is a new entry in the whitelist. And if need be, that whitelist can extend to individual bits.
You're absolutely right that developers don't need this functionality. Users do. msr-safe allows users to get access to benign MSRs that either don't have kernel interfaces yet or whose kernel interfaces don't meet their specialized needs. And we can provide this access on production machines without risking inadvertent or malicious scribbling on non-benign MSRs. And we can do this with one simple, straightforward kernel module.
If you have a better way of solving this problem, I'd love to hear it.
> >Thanks, > > tglx
Barry Rountree Center for Applied Scientific Computing Lawrence Livermore National Laboratory
>
| |