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.
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
> 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
> 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.