Greg KH <gre...@linuxfoundation.org> wrote: > Also, I think Alan's comment about it the last time it came up was more like > a "look at all of the other ways you could do bad things to hardware!" > comment, not a "you need to also do this thing too!" type of request.
Alan said: You need to filter or lock down kernel module options because a lot of modules let you set the I/O port or similar (eg mmio) which means you can hack the entire machine with say the 8250 driver just by using it with an mmio of the right location to patch the secure state to zero just by getting the ability to write to the modules conf file. I'm not entirely sure how one would do it, but Alan seems to think it can be done. > First off, this "secure boot support" massive patchset has not gone > anywhere yet, so why do this now? To continue quoting Alan: Without that at least fixed I don't see the point in merging this. Either we don't do it (which given the level of security the current Linux kernel provides, and also all the golden key messups from elsewhere might be the honest approach), or at least try and do the job right. Alan also said this: It is - so pushing something with known trivial holes isn't a useful way to do this. The module parameter hole needs to be addressed before this is fit for upstream. So you and Alan present something of a conflict of ordering: for Alan, I have to fix the module parameter hole first; for you, I have to do the secure boot support first. > So, what are you really trying to "block" here? The ability for someone > to set an i/o port value? why? Why does it matter what root sets for > an irq? For a dma buffer? For anything else? What is preventing this > going to "secure" somehow? I'll grant that prohibiting the changing of irq settings or dma channel settings may not actually be necessary. However, annotation module parameters to indicate hardware resource configuration seems potentially useful in its own right - and lets the policy be decided later. Setting ioports and iomem might allow you to get a driver for one piece of hardware to do something nasty with an unrelated piece of hardware. I really need Alan to weigh in on this. David