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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 06 Dec 2016 10:54:18 +0000
From:   David Howells <dhowells@...hat.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     dhowells@...hat.com, Matthew Garrett <mjg59@...f.ucam.org>,
        linux-kernel@...r.kernel.org, gnomes@...rguk.ukuu.org.uk,
        linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
        minyard@....org
Subject: Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

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