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]

Message-ID: <20161201150135.GA10317@kroah.com>
Date:   Thu, 1 Dec 2016 16:01:35 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     David Howells <dhowells@...hat.com>
Cc:     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)

On Thu, Dec 01, 2016 at 12:29:47PM +0000, David Howells wrote:
> Provided an annotation for module parameters that specify hardware
> parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
> dma buffers and other types).
> 
> This will enable such parameters to be locked down in the core parameter
> parser for secure boot support.

ick ick ick.

First off, this "secure boot support" massive patchset has not gone
anywhere yet, so why do this now?  Also, I think Alan's comment about it
the last time it came up was more like a "look at all of the other ways
you could do bad things to hardware!" comment, not a "you need to also
do this thing too!" type of request.

I certianly do not see how this makes anything "more secure" at all.
And I thought the last time this came up, Linus also objected to it,
which is why the patchset never went anywhere.

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.

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?

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?

thanks,

greg k-h

[1] Really, do you trust random driver writers to get things more
    "correct" than allowing people to get their hardware to work
    properly with module parameters?  I know driver writers, and really,
    I trust users more than them...