lkml.org 
[lkml]   [2016]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
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

\
 
 \ /
  Last update: 2016-12-02 04:49    [W:0.275 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site