Re: [PATCH 0/6] MODSIGN: Kernel module signing
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
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
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
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
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