[Openswan dev] moving crypto into the kernel

[Nick Jones]

On Tue, 2010-07-20 at 20:48 -0400, Paul Wouters wrote:
> Some interesting ideas:
> 
> https://fedoraproject.org/wiki/Features/CryptographyInKernel
> 

I wonder how this proposal will affect the crypto consolidation effort?:

https://fedoraproject.org/wiki/FedoraCryptoConsolidation

I think both could be carried out in parallel, but a new library will
need to be implemented that provides an api and semantics identical to
nss, but wraps around the kernel crypto interface.  Also, depending on
the progress of the consolidation effort, an openssl identical api and
wrapper will likely be required as well.

My first impression of using a device node interface to the crypto api
was slight confusion and doubt, but then again I haven't often used an
interface like this, so I'm not qualified to comment (but I will
anyhow!).

The Linux kernel has settled on fd interfaces to system level utilities
in the 2.6 series.  Examples of this are: signalfd: signals, eventfd:
now attached to various kernel activities to indicate change of state eg
aio completion, timerfd, inotify: monitor fs subtrees, epoll: a fd
interface to ... fd control!, all of these are welcome to anyone writing
software using an asynchronous event driven approach.
To be consistent, wouldn't a cryptofd interface be better?  Instead of
creating an initial fd through open("/dev/crypto", then having to manage
this initial fd and the session fds in a separate way (eg CLOEXEC
status, which I believe should be automatically ON for session fds and
my imagined cryptofd).  Reading the old documentation about the
openbsd /dev/crypto based framework, it seems OCF and the adapted
openssl implementations had to struggle in some ways deal with the two
stage session startup and teardown.  Also mentioned was the issue of
access to the crypto device inside a chroot.  I would hope the new linux
implementation can flatten some of these issues out.

To repeat, I have never used the openbsd crypto api, so I am not aware
of its strengths that I'm sure are significant and have grown out of
years of development and mindshare by people much smarter than myself.

Regardless of the interface, I think a crypto in kernel api for linux
has significant advantages, including but not limited to:
- Goes a long way to consolidating the crypto framework for all linux
applications.
- Promising in it can allow opaque usage of crypto hardware with
automatic software fallback. It would be nice to be able to query and
control this (hmm, maybe an initial /dev/crypto connection is a good
idea after all?).
- Would be feasable to advertise a host crypto api interface as a
virtual hardware device that re-advertises the host hardware
capabilities to a guest operating system in a virtualisation
environment, thus: guest app -> guest kernel crypto api -> guest
hardware crypto device or guest kernel software fallback if hardware
operation not supported -> host kernel crypto api -> host crypto
hardware

Some strong disadvantages I can see:
- Obsoleting many userspace crypto libraries that have been proven over
the years and throwing out a lot of the development and validation
effort put in by many dedicated people.
- If the crypto implementations are not properly modularised, bugs and
security issues will need a reboot to fix.

  Nick