Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
In-Reply-To: <20161205154714.GA3353@kroah.com>
References: <20161205154714.GA3353@kroah.com> <20161202065530.GA19753@kroah.com> <148059537897.31612.9461043954611464597.stgit@warthog.procyon.org.uk> <148059538747.31612.8974972913601108271.stgit@warthog.procyon.org.uk> <20161201150135.GA10317@kroah.com> <20161202030700.GA21669@srcf.ucam.org> <23342.1480690762@warthog.procyon.org.uk>
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)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32244.1481021658.1@warthog.procyon.org.uk>
Content-Transfer-Encoding: 8BIT
Date: Tue, 06 Dec 2016 10:54:18 +0000
Message-ID: <32245.1481021658@warthog.procyon.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2246
Lines: 50

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