Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

[David Howells]

Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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