cryptodev / softcrypto — are here any plans to cleanup it?

[Lev Serebryakov]

To be honest, I'm surprised by inconsistency of our kernel crypto
infrastructure.

"struct enc_xform" contains context size, but "struct auth_hash" doesn't.

Memory management is different for auth algorithms and encryption
algorithms.

There is Setkey for auth algorithms, but it is mostly unused.

There is no way to re-key encryption without re-allocating context
("key" or "schedule", even naming is not consistent). Ouch.

As I could see by commits, there was some simplifications , but,
maybe, here is project to cleanup this subsystem?

[John Baldwin]

Post by Lev Serebryakov
To be honest, I'm surprised by inconsistency of our kernel crypto
infrastructure.
"struct enc_xform" contains context size, but "struct auth_hash" doesn't.
Memory management is different for auth algorithms and encryption
algorithms.
There is Setkey for auth algorithms, but it is mostly unused.
There is no way to re-key encryption without re-allocating context
("key" or "schedule", even naming is not consistent). Ouch.
As I could see by commits, there was some simplifications , but,
maybe, here is project to cleanup this subsystem?

I have some WIP to rework the interface between OCF and backend drivers
including cryptosoft. However, it doesn't really address any of the issues
you raised. I would actually prefer it if we removed rekeying from OCF
sessions (requiring new sessions for new keys). geli(4) is the only OCF
consumer that changes keys on existing sessions. It would make some of
the framework simpler (and would make the code that tries to migrate
existing ops to a new session less fragile) if we bound keys to sessions
and required keys during session creation.

You can see my WIP here:
https://github.com/freebsd/freebsd/compare/master...bsdjhb:ocf_rework