linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: dhowells@redhat.com, kyle@mcmartin.ca, dmitry.kasatkin@intel.com,
	zohar@linux.vnet.ibm.com, 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: Tue, 05 Jun 2012 14:35:56 +0100	[thread overview]
Message-ID: <18581.1338903356@redhat.com> (raw)
In-Reply-To: <87ipf73lsi.fsf@rustcorp.com.au>

Rusty Russell <rusty@rustcorp.com.au> wrote:

> > If you prefer to have userspace extract the module signature and pass it in
> > uargs, here's a tree that will do that:
> > 
> > 	http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/modsign-uarg
> 
> OK, there's merit in this approach: it certainly moves the argument
> about how to encode the signature out of my backyard :)

Not really.  The signature still has to be created by the kernel build.  It's
just that you no longer have to care about the trade off when it comes to
parsing it.

> Should we just bite the bullet and create a new syscall:
> 
> SYSCALL_DEFINE5(init_module2, void __user *, umod,
> 		unsigned long, len, const char __user *, uargs,
>                 unsigned int, siglen, const char __user *, sig)
> 
> But I'm easily swayed if you prefer the current approach.

"The current approach" being to attach signature to the blob?  Or to pass the
signature separately but in the uargs?

I would very much prefer to keep the signature in the blob and have the kernel
extract it as there's no particular need for it to be detached - even if you
are using IMA.

However, I don't think an extra syscall would hurt particularly - except that
it uses up more space in the syscall table...  It would, however, be smaller
in the signature verification department as the signature neither needs
decoding from uargs nor extracting from the blob.

David

  parent reply	other threads:[~2012-06-05 13:36 UTC|newest]

Thread overview: 55+ 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
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  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 [this message]
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=18581.1338903356@redhat.com \
    --to=dhowells@redhat.com \
    --cc=dmitry.kasatkin@intel.com \
    --cc=keyrings@linux-nfs.org \
    --cc=kyle@mcmartin.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=zohar@linux.vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).