Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Linus Torvalds


On Wed, 14 Feb 2007, David Howells wrote:

  (1) A cut-down MPI library derived from GPG with error handling added.

Do we really need to add this?

Wouldn't it be much nicer to just teach people to use one of the existing 
signature things that we need for _other_ cases anyway, and already have 
merged?

(Of course, it's possible that none of the current crypto supports any 
signature checking at all - I didn't actually look. In which case my 
argument is pointless).

Linus
-
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
Linus Torvalds [EMAIL PROTECTED] wrote:

   (1) A cut-down MPI library derived from GPG with error handling added.
 
 Do we really need to add this?

I presume you mean the MPI library specifically?  If so, then yes.  It's
necessary to do DSA signature verification (or RSA for that matter).

 Wouldn't it be much nicer to just teach people to use one of the existing 
 signature things that we need for _other_ cases anyway, and already have 
 merged?

Existing signature things?  I know not of such beasts, nor can I see them
offhand.

 (Of course, it's possible that none of the current crypto supports any 
 signature checking at all - I didn't actually look. In which case my 
 argument is pointless).

Hashing, yes; encryption, yes; signature checking: no from what I can see.

It's possible that I can share code with eCryptFS, though at first sight that
doesn't seem to overlap with what I want to do.

David
-
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread David Howells
Michael Halcrow [EMAIL PROTECTED] wrote:

 Right now, eCryptfs just delegates its modular exponentiation
 operations to a userspace daemon. If RSA ever finds its way into the
 kernel, I might tweak eCryptfs to use that instead for some of the
 public key operations.

Am I right in thinking that RSA uses many of the same MPI lib bits as DSA?

David
-
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Michael Halcrow
On Wed, Feb 14, 2007 at 09:59:37PM +, David Howells wrote:
 Michael Halcrow [EMAIL PROTECTED] wrote:
 
  Right now, eCryptfs just delegates its modular exponentiation
  operations to a userspace daemon. If RSA ever finds its way into the
  kernel, I might tweak eCryptfs to use that instead for some of the
  public key operations.
 
 Am I right in thinking that RSA uses many of the same MPI lib bits
 as DSA?

I would imagine so. Assuming we aren't having to hassle with key
generation (eCryptfs takes care of that in userspace), then RSA is,
more or less, a^b mod c (mpi_mulpowm() and friends).

Mike
-
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Andrew Morton
On Wed, 14 Feb 2007 19:09:38 + David Howells [EMAIL PROTECTED] wrote:

 These patches provide a GPG-based kernel module signing facility.  Their use 
 is
 not fully automated within the confines of the kernel build process because it
 needs provision of keys from outside of the kernel before the kernel can be
 compiled.
 
 The patches are:
 
  (1) A cut-down MPI library derived from GPG with error handling added.
 
  (2) Permit hash algorithms to hash kernel data defined by a virtual address
  and a length rather than trying to use scattergather lists (which require
  struct page pointers to be determined).
 
  (3) Add extra information to the per-arch ELF headers to more fully describe
  the format of the ELF metadata.
 
  (4) Add module verification capabilities, including ELF metadata 
 verification.
 
  (5) Add a generic DSA signature checker.  Given a SHA1 hash of the data to be
  verified and a binary blob holding a GPG signature stream, this verifies
  the signature using a built-in ring of public keys.
 
  (6) Add a module signature checker that applies signature checking to modules
  on module load, checking the signature against the ring of public keys
  compiled into the kernel.

Grand total:

 77 files changed, 9681 insertions(+), 10 deletions(-)

just to be able to sign modules.

Normally I'd collapse writhing in laughter, but..

 These patches have been in use by RHEL and Fedora kernels for years, and so
 have been thoroughly tested.

so I guess there's an argument for merging them so we can send them back to
you guys.  But there's also an argument to declare all this gunk a
vendor-only thing.  How much pain would that cause?
-
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html