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

From: David Howells <dhowells@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: dhowells@redhat.com, Matthew Garrett <mjg59@srcf.ucam.org>,
	linux-kernel@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	minyard@acm.org
Subject: Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
Date: Tue, 06 Dec 2016 10:54:18 +0000	[thread overview]
Message-ID: <32245.1481021658@warthog.procyon.org.uk> (raw)
In-Reply-To: <20161205154714.GA3353@kroah.com>

Greg KH <gregkh@linuxfoundation.org> 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