Date: Thu, 1 Nov 2018 12:00:16 -0700 From: John Baldwin <jhb@FreeBSD.org> To: lev@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-security@freebsd.org Subject: =?UTF-8?Q?Re:_cryptodev_/_softcrypto_=e2=80=94_are_here_any_plans_t?= =?UTF-8?Q?o_cleanup_it=3f?= Message-ID: <f790ad55-795e-5ad5-b32b-088373e43a11@FreeBSD.org> In-Reply-To: <e7cbc29c-2095-00e0-76cd-b2bfe5598a5a@FreeBSD.org> References: <e7cbc29c-2095-00e0-76cd-b2bfe5598a5a@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/16/18 11:59 AM, Lev Serebryakov wrote:
>
> 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
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f790ad55-795e-5ad5-b32b-088373e43a11>