From: Rusty Russell <rusty@rustcorp.com.au>
To: Josh Boyer <jwboyer@gmail.com>
Cc: David Howells <dhowells@redhat.com>,
kyle@mcmartin.ca, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, keyrings@linux-nfs.org
Subject: Re: [PATCH 00/23] Crypto keys and module signing
Date: Mon, 04 Jun 2012 10:46:01 +0930 [thread overview]
Message-ID: <87lik33mi6.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CA+5PVA5qCiYNppOBihKfsqvyNWwBsBsyGD7SmJaphV_67HG1aQ@mail.gmail.com>
On Thu, 31 May 2012 11:35:23 -0400, Josh Boyer <jwboyer@gmail.com> wrote:
> On Sun, May 27, 2012 at 1:41 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > On Thu, 24 May 2012 15:00:51 +0100, David Howells <dhowells@redhat.com> 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.
>
> Could you elaborate on this part a bit? Do you mean integrate a
> standalone strip utility in the kernel sources and maintain that for
> use during module builds? Or am I misunderstanding and you meant
> something else?
In the kernel sources, no. But could RH maintain such a thing? Surely.
Whether they want to guarantee that their strip is stable on kernel
modules, or create a minimal 'kmod-strip' is up to them.
> I can see how that sounds simple and desirable from one aspect, but
> it seems somewhat odd to me to duplicate the existing (or create from
> scratch) strip utilities.
Mangling a module after it is signed is very odd, and odd things aren't
nice for security features. That's how we got here; I'm trying to move
the oddness out of the verification path.
Cheers,
Rusty.
next prev parent reply other threads:[~2012-06-04 4:49 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 23:02 [PATCH 00/23] Crypto keys and module signing David Howells
2012-05-22 23:02 ` [PATCH 01/23] Guard check in module loader against integer overflow David Howells
2012-05-22 23:02 ` [PATCH 02/23] KEYS: Move the key config into security/keys/Kconfig David Howells
2012-05-22 23:02 ` [PATCH 03/23] KEYS: Announce key type (un)registration David Howells
2012-05-22 23:02 ` [PATCH 04/23] KEYS: Reorganise keys Makefile David Howells
2012-05-22 23:02 ` [PATCH 05/23] KEYS: Create a key type that can be used for general cryptographic operations David Howells
2012-05-22 23:03 ` [PATCH 06/23] KEYS: Add signature verification facility David Howells
2012-05-22 23:03 ` [PATCH 07/23] KEYS: Asymmetric public-key algorithm crypto key subtype David Howells
2012-05-22 23:03 ` [PATCH 08/23] KEYS: RSA signature verification algorithm David Howells
2012-05-22 23:03 ` [PATCH 09/23] Fix signature verification for shorter signatures David Howells
2012-05-22 23:03 ` [PATCH 10/23] PGPLIB: PGP definitions (RFC 4880) David Howells
2012-05-22 23:03 ` [PATCH 11/23] PGPLIB: Basic packet parser David Howells
2012-05-22 23:03 ` [PATCH 12/23] PGPLIB: Signature parser David Howells
2012-05-22 23:03 ` [PATCH 13/23] KEYS: PGP data parser David Howells
2012-05-22 23:04 ` [PATCH 14/23] KEYS: PGP-based public key signature verification David Howells
2012-05-22 23:04 ` [PATCH 15/23] KEYS: PGP format signature parser David Howells
2012-05-22 23:04 ` [PATCH 16/23] KEYS: Provide a function to load keys from a PGP keyring blob David Howells
2012-05-22 23:04 ` [PATCH 17/23] MODSIGN: Provide gitignore and make clean rules for extra files David Howells
2012-05-22 23:04 ` [PATCH 18/23] MODSIGN: Provide Documentation and Kconfig options David Howells
2012-05-22 23:04 ` [PATCH 19/23] MODSIGN: Sign modules during the build process David Howells
2012-05-22 23:04 ` [PATCH 20/23] MODSIGN: Provide module signing public keys to the kernel David Howells
2012-05-22 23:05 ` [PATCH 21/23] MODSIGN: Module signature verification David Howells
2012-05-22 23:05 ` [PATCH 22/23] MODSIGN: Automatically generate module signing keys if missing David Howells
2012-05-22 23:05 ` [PATCH 23/23] MODSIGN: Panic the kernel if FIPS is enabled upon module signing failure David Howells
2012-05-23 12:51 ` [PATCH 00/23] Crypto keys and module signing Rusty Russell
2012-05-23 14:20 ` David Howells
2012-05-24 12:04 ` Rusty Russell
2012-05-24 14:00 ` David Howells
2012-05-27 5:41 ` Rusty Russell
2012-05-31 14:11 ` David Howells
2012-05-31 15:35 ` Josh Boyer
2012-06-04 1:16 ` Rusty Russell [this message]
2012-06-04 13:38 ` Josh Boyer
2012-06-05 0:23 ` Rusty Russell
2012-06-22 1:53 ` Greg KH
2012-06-22 3:29 ` Lucas De Marchi
2012-06-22 3:29 ` Lucas De Marchi
2012-06-22 4:05 ` Rusty Russell
2012-06-22 11:03 ` David Howells
2012-06-23 0:20 ` Rusty Russell
2012-05-25 11:15 ` Kasatkin, Dmitry
2012-05-25 11:37 ` David Howells
2012-05-25 13:08 ` Mimi Zohar
2012-05-25 13:53 ` David Howells
2012-05-25 14:40 ` Mimi Zohar
2012-05-25 12:18 ` David Howells
2012-05-25 15:42 ` David Howells
2012-06-04 1:31 ` Rusty Russell
2012-06-04 12:47 ` Mimi Zohar
2012-06-05 1:05 ` Rusty Russell
2012-06-05 11:39 ` Mimi Zohar
2012-06-05 13:37 ` David Howells
2012-06-05 14:36 ` Kasatkin, Dmitry
2012-06-05 13:35 ` David Howells
2012-06-10 5:47 ` Rusty Russell
2012-06-11 8:30 ` Kasatkin, Dmitry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lik33mi6.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=dhowells@redhat.com \
--cc=jwboyer@gmail.com \
--cc=keyrings@linux-nfs.org \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.