Re: [PATCH] /dev/crypto for Linux

[Bill Davidsen <davidsen@tmr.com>]

James Morris wrote:
> On Tue, 24 Aug 2004, Michal Ludvig wrote:
> 
> 
>>How does it work?
>>- - Process opens /dev/crypto and with a set of ioctl() commands does what
>>it wants to. I.e. obtains a crypto session, does the {enc,dec}ryption
>>and finally closes the session. The sessions are bound to "struct file"
>>of the open /dev/crypto and thus are automatically removed even if the
>>process dies unexpectedly.
> 
> 
> I don't think this is the way forward for the user crypto API.  Rather 
> than using the openbsd device as a starting point, we need to look at what 
> is the best for Linux and work from there.
> 
> In any case, the openbsd device is the wrong model.  An ioctl() based 
> interface is just a set of backdoor syscalls, but with weak semantics, and 
> a potential maintenance nightmare.
> 
> At this stage, the only real use for the device is to make it easier to 
> test and benchmark the crypto modules, and I'm not sure if this is enough 
> justification for integration with the kernel at this stage.  Currently, 
> the tcrypt module provides a convienient way to test modules on whatever 
> architecture you can boot a kernel on, without the need for external 
> userspace packages.  It also tests some specific scatterlist cases.  So, 
> your crypto dev would not likely be considered a full replacement for 
> tcrypt at this stage.

The use of this would be to provide some access to crypto for portable 
programs which might be usefully run on systems which have not installed 
the big libs needed for usermode crypto. And it also addresses the 
reality that many people update their kernel more often than their libs, 
and new methods are more likely to be available there. For a low-volume 
task like encoding a key or other small chunk of data it might be that 
the overhead of the system call would be no more than the memory 
footprint of loading a lib to do a single operation.

And every time I see a new method in the kernel, I wonder why it's there 
is users can't access it?

Don't take this as a stand to include this, I'm just being devil's 
advocate and bringing up the benefits since multiple people are bringing 
up the drawbacks. If this was actually going to happen it *might* be 
done with a totally different interface and happen in a kernel thread or 
some such. One feature of MULTICS we don't have is the ability to 
execute kernel code in user mode, sort of like a shared library.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me