[PATCH] /dev/crypto for Linux

[Michal Ludvig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Morris told me that:

> An open("/cryptoapi/cipher/aes/transform") would cause the kernel to
> allocate a tfm, which could then be managed by writing to xattrs
> associated with the device:
>    key
>    iv
>    mode (encrypt/decrypt, ecb/cbc etc)
>
> So, to set the key, you'd use fsetxattr(fd, "crypto.key", key, size, 0),
> or something.

Why is using xattrs better than using ioctls? I thought that xattrs are
something persistent on the filesystem, i.e. once set it would be used
for all future openings of the transform device until reset to a
different value...?

> To encrypt, you'd write plaintext to the device.  The ciphertext would be
> available on the next read (using the transaction based IO file code now
> in libfs).

How are the transactions used from the userspace? How would the process
know which read ciphertext is a transform of which written plaintext?
Should it count the bytes itself to stay in sync? Most often the lengths
of plaintext and ciphertext are the same, but e.g. for hashes and
compressors it isn't that easy... Will there be a kind of notification
telling where the compressed stream corresponding to the written input ends?

> The transform device (and possibly the directory) would be private views
> on a per-open basis.  If a crypto module was not loaded, trying to access
> its directory would cause an attempt to load the relevant module
(although
> I'm not sure how to allow an unprivileged user to do this safely).

The kernel can request module loading, can't it? So if the user attempts
to open cipher/aes the kernel could try to load a module e.g. with alias
'cipher-aes'. Or is this a security hole?

Also it should be possible to enable/disable autoload and once loaded
enable/disable usage of the module from userspace.

> Another unresolved issue is how to allow the specification of different
> types of drivers (e.g. specific hardware device, asm-only etc).

How about having cipher/aes/<modulename>/{transform,info}? Also there
could be cipher/aes/default symlink pointing to the prefered module.
Each module could have a "preference level", e.g. generic C
implementation, optimized asm, a hardware device, or administrator
specified preference.

> I would also not expect applications to use this filesystem directly,
> there would be some nice userspace glue library to abstract things out and
> make it look like a typical userspace crypto library.  Also worth
> investigating would be integration of common crypto libraries so that
they
> can make use of crypto hardware fairly transparently.

OpenSSL provides a concept of "Engines" that could be used for this
(there already is an engine for the OpenBSD style /dev/crypto that I
modified to work with my Linux port).

> I'm hoping to do some work on this over the next few weeks (well, the
> transaction based IO consolidation into libfs was actually some initial
> work), but any further design/discussion/coding is definitely welcome.

Although I have never been writing a filesystem I would really like to
participate on the work (and hopefully even time permits ;-)

Michal Ludvig
- --
SUSE Labs                    mludvig at suse.cz
(+420) 296.542.396        http://www.suse.cz
Personal homepage http://www.logix.cz/michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBL0QyDDolCcRbIhgRAocMAKC/9zOdG6fYQulN0aUjnpDYyFriNgCePpUn
tkPVA4hpk+/dKSyuXxyKaXs=
=JMTq
-----END PGP SIGNATURE-----