Date: Mon, 5 Dec 2016 21:26:41 +0000
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
        David Howells <dhowells@redhat.com>, linux-kernel@vger.kernel.org,
        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)
Message-ID: <20161205212641.615f2610@lxorguk.ukuu.org.uk>
In-Reply-To: <20161202071246.GA27889@srcf.ucam.org>
References: <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>
        <20161202065530.GA19753@kroah.com>
        <20161202071246.GA27889@srcf.ucam.org>
Organization: Intel Corporation
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1728
Lines: 34

> If the parameters plausibly make it possible for root to modify the 
> kernel in interesting ways, then restricting them makes sense. My gut 
> sense is that parameters that allow the alteration of the base address 
> of memory mapped devices are clearly a problem in this respect, but port 
> io and IRQs *probably* aren't. On the other hand, blocking mmio base 
> addresses and not blocking the others is kind of inconsistent.

It is actually useful even without secure boot because right now
DAC capability bypass is easier to get and gives you CAP_SYS_RAWIO if
you've mastered your first class in being an 3733t h4x0r. (because you can
modify /etc/moprobe.d/* and even with signed modules that's not
protected).

It's also the case if you go through those drivers that pretty much none
of them are found on a modern EFI and secure boot enabled system and
those that are will be using ACPI, PCI, devicetree or other reliablish
bus enumerations instead. The cross section of people needing io=foo, and
having secure boot is close to nil.

> This is a logical extension to the base patchset, and one maintainer has 
> NAKed the base patchset due to it lacking this feature. If you don't 
> care about this then just tell Alan that you want the base patchset 
> merged anyway and we'll go from there. Let's not get into a situation 
> where people are being given incompatible requirements before 
> something's merged.

The base patchset actually doesn't do anything without it. I'd hope the
vendors adopt it anyway if they are serious about secure boot (or
security in general) given it's really valuable even without the secure
boot firmware nonsense to be able to boot a machine and then lock down
raw I/O access.

Alan