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

[Aaron LI]

On 4/4/25 4:41 PM, Michael Neumann wrote:
> On Fri, Apr 04, 2025 at 09:45:00AM +0800, Aaron LI wrote:
>> On 4/4/25 3:35 AM, Michael Neumann wrote:
>>>
>>> * /dev/crypto is gone
>>
>> Will this change require modifications to OpenSSL/LibreSSL/OpenSSH etc.
>> software?
> 
> No.

Cool!

> 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.

Nice to know.

>>> * 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?

Don't think our version is up-to-date with the upstream.  I think it 
worthies a sync.

I think it doesn't hurt to push the changes/fixes to the upstream, and 
it would be much better if merged.

> 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

I knew this bug report and had a simple look. I was suspecting some 
missing kfree() in opencrypto.  Does it still panic due to malloc limit 
exceeded after your crypto overhaul?

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

This would be good. IIRC it already links to libcrypto, so I don't know 
why it requires /dev/crypto since the actual crypto ops are performed in 
dm_target_crypt.

Cheers,
Aaron