Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754510AbcLBDsv (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Dec 2016 22:48:51 -0500
Received: from cavan.codon.org.uk ([93.93.128.6]:37639 "EHLO
        cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751227AbcLBDst (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Dec 2016 22:48:49 -0500
X-Greylist: delayed 2460 seconds by postgrey-1.27 at vger.kernel.org; Thu, 01 Dec 2016 22:48:48 EST
Date: Fri, 2 Dec 2016 03:07:00 +0000
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: David Howells <dhowells@redhat.com>, 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)
Message-ID: <20161202030700.GA21669@srcf.ucam.org>
References: <148059537897.31612.9461043954611464597.stgit@warthog.procyon.org.uk>
 <148059538747.31612.8974972913601108271.stgit@warthog.procyon.org.uk>
 <20161201150135.GA10317@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161201150135.GA10317@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk
X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2579
Lines: 51

On Thu, Dec 01, 2016 at 04:01:35PM +0100, Greg KH wrote:

> First off, this "secure boot support" massive patchset has not gone
> anywhere yet, so why do this now?

Because David ended up with the short straw when distro maintainers 
talked about this at LPC.

> Secure boot is a trust that the previous boot process is now booting
> your image that it feels is secure (with various levels of "secure").
> It is not about "lock things down so no one can ever touch the hardware
> through different options, except through random logic[1] that we
> somehow trust "more" than configuration options.

If root is able to modify the behaviour of verified code after it was 
verified, then the value of that verification is reduced. Ensuring that 
the code remains trustworthy is vital in a number of security use cases.

> So, what are you really trying to "block" here?  The ability for someone
> to set an i/o port value?  why?  Why does it matter what root sets for
> an irq?  For a dma buffer?  For anything else?  What is preventing this
> going to "secure" somehow?

If root can tell a driver to probe for hardware at a specific address, 
and that driver will then blindly do so, root is trivially able to 
modify arbitrary kernel memory and disable arbitrary security features. 
IRQ or io port attacks are much more difficult to take advantage of, but 
I could imagine that some of them are still plausible.

> Overall, I really don't like this, and honestly, don't like the whole
> "secure boot" patchset either, as it is really a lot of work for
> absolutely no gain that I can see.  Who is "asking" for this type of
> thing, and what are their specific requirements?

Here's an example. The sysfs option to enable module signing is write 
once. If root sets that, root can't unset it. Except there's a whole 
bunch of ways that root *can* unset it, including kexec 
(https://mjg59.dreamwidth.org/28746.html) and a bunch of other things 
that are disabled by this patchset. That feature is entirely useless as 
is. This patchset helps make it useful.

Right now, the secure boot patchset is shipped by basically every single 
mainstream Linux distribution (and a whole bunch that are niche). Right 
now they're having to do extra work to rebase it and ensure that fixes 
get distributed to everyone. There's clearly demand, and Linus has been 
clear that features that are shipped by everyone should just go into 
mainline, so if there are *technical* objections then let's figure them 
out and otherwise just get this stuff merged.

--
Matthew Garrett | mjg59@srcf.ucam.org