linux-kernel - Re: [PATCH 00/23] Crypto keys and module signing

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: <20120622015341.GA3414@kroah.com>
Date:	Thu, 21 Jun 2012 18:53:41 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	David Howells <dhowells@...hat.com>, kyle@...artin.ca,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Re: [PATCH 00/23] Crypto keys and module signing

On Sun, May 27, 2012 at 03:11:23PM +0930, Rusty Russell wrote:
> > > > Why would you want multiple signatures?  That just complicates things.
> > > 
> > > The code above stays pretty simple; if the signature fails, you set size
> > > to i, and loop again.  As I said, if you know exactly how you're going
> > > to strip the modules, you can avoid storing the stripped module and
> > > simply append both signatures.
> > 
> > You still haven't justified it.  One of your arguments about rejecting the ELF
> > parsing version was that it was too big for no useful extra value that I could
> > justify.  Supporting multiple signatures adds extra size and complexity for no
> > obvious value.
> 
> One loop is a lot easier to justify that the ELF-parsing mess.  And it
> can be done in a backwards compatible way tomorrow: old kernels will
> only check the last signature.
> 
> I had assumed you'd rather maintain a stable strip util which you can
> use on kernel modules than rework your module builds.  I guess not.

To dig an old thread up, but what really is wrong with the original ELF
section stuff?  Why encode "magic" values on the end of the kernel
module that then require all userspace tools to be modified in order to
properly handle this?

When I first did this so many many years ago an elf section made it so
easy to handle.  Userspace didn't need to be modified, and everyone
knows how to handle elf sections, even the kernel does :)

And I think we really want the ability to have multiple signatures, the
whole "chain of trust" thing that is needed will work out much better if
multiple signatures are allowed.  Putting it in an elf section allows
this to work out easier, right?

confused,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/