Upcoming changes to crypto(9) and dm_target_crypt(4)

[Michael Neumann]

On Fri, Apr 04, 2025 at 09:45:00AM +0800, Aaron LI wrote:
> On 4/4/25 3:35 AM, Michael Neumann wrote:
> > Hi,
> > 
> > I've been working on this for a while. Now it is fairly stable -
> > I am running this since a few days on my laptop with sensible data.
> > 
> > The patch is massive mainly because it gets rid of plenty of legacy
> > code!
> 
> Hi Michael, great job. Thanks.

You're welcome!

> > The patch is here:
> > 
> > https://leaf.dragonflybsd.org/~mneumann/0001-Retire-crypto-9-and-tcplay-8-and-refactor-dm_target_.patch
> > 
> > Summarising the changes:
> > 
> > * crypto(9) (opencrypto) is gone
> > 
> > * /dev/crypto is gone
> 
> Will this change require modifications to OpenSSL/LibreSSL/OpenSSH etc.
> software?

No.

Our version of OpenSSL does not ship with the cryptodev engine.  Note
that OpenSSL is capable of doing all crypto in userland without any help
of special kernel features. For instance, it bundles AESNI assembly
here:

	/usr/src/crypto/libressl/crypto/aes/aesni-elf-x86_64.S 

Using cryptodev engine, which AFAIK would only work on FreeBSD, should
actually be much slower as compared to using the AESNI assembly from
OpenSSL.

OpenSSL in ports might ship with cryptodev engine but it should not be
used on DragonFly! It should compile and decide at runtime "/dev/crypto"
is not there so skip it.

> 
> > * tcplay(8) is gone
> 
> Hmm, I'd not just remove tcplay(8). As alexh said (in
> https://github.com/bwalex/tc-play ) it's quite robust and mature. And the
> upstream also added VeraCrypt support.

Ok. I think we can make it work :).

We might need to patch it slightly... and the question arises if we want
to keep it in our src tree or move it out as a port? Is the current
version in src up-to-date?

tcplay depends on /dev/crypto which I really would like to get rid of
for various reasons.

One is, I can reproducibly crash the kernel by using tcplay:

	https://bugs.dragonflybsd.org/issues/3370

Throughout the entire DragonFly code base, there are only two
consumers of the opencrypto API/cryptodev:

	* tcplay (uses /dev/crypto)
	* dm_target_crypt (uses in-kernel opencrypto API) 

Should not be too hard to change tcplay to use a crypto function from
OpenSSL.

About the removal of /dev/crypto:

	"The /dev/crypto pseudo-device was removed from OpenBSD in version 5.7
	and replaced by the crypto_ suite of syscalls."

OpenBSD removed /dev/crypto and heavily refactored the in-kernel API.
AFAIK, FreeBSD kept /dev/crypto but significantly changed the in-kernel
API.

> > Feel free to comment and test. If there are no objections, I'd love
> > to commit this in the coming weeks, either as one huge commit, or
> > maybe splitting it up into more digestable changes?
> 
> I'd like separate commits.  Easy to reason and blame in the future.

Makes sense.

So I'd go as follows:

* Remove hifn(4), safe(4), ubsec(4) and padlock(4) drivers. These  were
  removed in OpenBSD 7.1 and it's unlikely that they are still in use by
  someone. On i386 or very old CPUs (before 2010) w/o AESNI hardware, it
  might make sense to have them, given you have the hardware crypto
  accelerators.

* Then, move the aesni assembly from sys/dev/crypto/aesni to
  sys/crypto/aesni and also remove aesni(4). There is no point in using 
  AESNI (a CPU instruction) via /dev/crypto other than massively slowing
  down things.

* Then, make my changes to dm_target_crypt while still keeping the
  crypto(9) API and /dev/crypto. But, dm_target_crypt will only support
  AES ciphers (due to lack of testing). Note that as tcplay uses
  dm_target_crypt under the hood, tcplay will likewise loose the
  Serpent and Twofish ciphers. It's easy to bring them back if needed.
  But, no one in DragonFly seems to be using them.

Now we can try to fix tcplay to avoid using /dev/crypto. Once done:

* Get rid of cryptodev (/dev/crypto)

* Get rid of opencrypto framework

(last two points are optional).

If that makes sense, I'll give it a go :)

Regards,

  Michael

> 
> Cheers,
> Aaron
> 

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de