lkml.org 
[lkml]   [2012]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 00/23] Crypto keys and module signing
Date
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


\
 
 \ /
  Last update: 2012-06-05 16:21    [W:0.165 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site