Re: [PATCH] /dev/crypto for Linux

[James Morris]

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.

I would also want to see the user API evolve with the development of 
hardware crypto support, and not lock us into forever supporting some 
potentially inadequate/broken model.  So, any user API at this stage 
should be marked experimental if it is going to be merged, if at all.

I think there are really two options for developing the user API:

1) a set of syscalls, or
2) a filesystem.

The main idea being to provide a well-structured, text-based (as far as
possible) API with strong semantics.  I have a preference for a filesystem
API (and done some initial design), but have not established yet whether
it is feasible compared to the syscall approach.

I would encourage you to look at a filesystem API, as a project which 
evolves with the addition of hardware support.  I guess this is something 
we could discuss in more detail on the crypto list rather than annoy the 
lkml folk with.


- James
-- 
James Morris
<jmorris@xxxxxxxxxx>



-
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/