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

[David Howells]

Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

> > Because Alan says that locking down the module parameters needs to be done
> > first.  Since I had to go through and modify each module parameter to mark the
> > hardware config ones, it seemed like a good opportunity to label their type
> > (ioport, iomem, irq, etc.) whilst I was at it.
> > 
> > > Then just mark them all as "bad", why pick and choose?
> > 
> > Because some drivers, IPMI for example, can also be autoconfigured via PCI,
> > PNP, ACPI or whatever and still be useful, if not important, to the system's
> > operation.
> > 
> > Simply marking all drivers that can be so configured as "bad" and rejecting
> > them outright in lockdown mode is a non-starter.
> 
> Sorry, I meant to mark all of these types of attributes as "bad", not
> trying to classify all of the different types of attributes, given that
> you will probably want to just ban all of them or none, right?

That was my intent.  However, since I was touching every hardware module param
anyway, it seemed like a good thing to add.  At least now one can grep for
every config param that explicitly sets a DMA channel, for example.

> I'll defer to Alan as to what he feels is needed here, given that this
> patchset isn't being shipped by anyone I think it's odd to somehow make
> this a pre-requisite for anything to be merged as no real user of the
> patchset seemed to feel this type of thing was needed :)

But unless I post it, no one's going to review it.  Granted, I should probably
have stuck "RFC" in the subject.

> >  (4) System blacklist.  List hashes to be blacklisted.  This is independent
> >      of all other series.
> 
> These are hashes of what?

Hashes of module content, kexec image content, X.509 toBeSigned content,
firmware blobs.  Things that are going to get hashes blacklisted in the UEFI
database.

> I think patch 3 is going to be the "hardest", along with 2, given the
> large area it touches.  Why not work on the other bits first?

Because not everyone agrees with you on the order.  Further, some of the bits
are independent - (2) vs (4)/(5) for example.  Besides, I have patchsets for
(1) and (3).  There is a patch in (3) that depends on (2), but that could be
moved across.

David