Ranting about OCF / crypto(9)

[John Baldwin]

On Thursday, January 11, 2018 07:46:24 AM Poul-Henning Kamp wrote:
> --------
> In message <3790717.UIxaijsHl3 at ralph.baldwin.cx>, John Baldwin writes:
> 
> >- OCF is over flexible and overly broad.
> 
> I would actually argue that it is neithe, quite the contrary.

>From a device driver's perspective it is overly broad.  The linked-list of
descriptors in theory allows arbitrary data arrangments, but all of the
recent crypto engines I'm familiar with basically cater to the layout of
IPSec and TLS.  They assume exactly one region of cipher text with an
optional AAD region that is before (not after), etc.  They don't support
arbitrary combinations of alorithms, and they make certain assumptions about
how combined auth+enc actually works.

> With the kernel-userland transition becoming more expensive, what
> we need is a DSL where you can put entire processing steps into the
> kernel, sort of like BPF but more general.
> 
> Ideally, you should be able to push something like this into
> the kernel and have it executed in a single syscall:
> 
> 	h = hash:sha256()
> 	b = file_buffer()
> 	f = open("/tmp/foo", "r")
> 	while f.read(b):
> 		h.input(b)
> 	return h.hex()
> 
> BPF is the existence proof that stuff like this is both
> feasible and profitable, now we just need to take it to
> the next level.
> 
> If we had a language like this, accept-filters whouldn't be
> necessary.

While I think this is not a bad idea, I don't think it has any bearing
on the crypto <-> driver interface which is where most of my beef lies,
but rather a different method to allow construction of in-kernel requests
to the crypto layer.

-- 
John Baldwin