Re: [PATCH] /dev/crypto for Linux
From: Bill Davidsen
Date: Wed Aug 25 2004 - 16:48:11 EST
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@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/