From owner-freebsd-hackers@freebsd.org Thu Nov 1 19:00:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D57010FBD8B; Thu, 1 Nov 2018 19:00:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4984785D9E; Thu, 1 Nov 2018 19:00:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id C443910B476; Thu, 1 Nov 2018 15:00:17 -0400 (EDT) Subject: =?UTF-8?Q?Re:_cryptodev_/_softcrypto_=e2=80=94_are_here_any_plans_t?= =?UTF-8?Q?o_cleanup_it=3f?= To: lev@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-security@freebsd.org References: From: John Baldwin Message-ID: Date: Thu, 1 Nov 2018 12:00:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 01 Nov 2018 15:00:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 19:00:19 -0000 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