News: 0001540316

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

DragonFlyBSD Lands "Next-Gen" Disk Encryption Code

([BSD] 6 Hours Ago dm_target_crypt_ng)


It's been a while since having any exciting feature development to talk about with DragonFlyBSD but merged this past week was dm_target_crypt_ng, a next-generation implementation of their DM-crypt code for disk encryption.

DragonFlyBSD developer Michael Neumann re-engineered the DM-crypt code for this BSD operating system as this transparent disk encryption implementation compatible with Linux's dm-crypt.

Michael Neumann explained in the [1]initial commit landing this next-generation code:

"dm_target_crypt_ng - Add next-generation implementation

* No longer use opencrypto or cryptodev. These were asynchronous and caused a lot (!) of complications to the code.

* Instead, use our own set of crypto ciphers implemented in crypto_cipher.{c,h}, which is a simplified API to use symmetric block ciphers. It mostly calls out to the actual crypto algorithm implementations contained under sys/crypto.

* Interactivity is greatly improved! When running "blogbench" with the old dm_target_crypt module, "blogbench" basically "freezes" the system at around 400 number blogs (Nb). The mouse cursor continuously freezes for about 1 second. While the computer becomes slower when running dm_target_crypt_ng, no lag of mouse can be observed. The final "blogbench" performance result stays about the same. For example:

# dm_target_crypt (old)

Final score for writes: 2136

Final score for reads : 200584

# dm_target_crypt_ng (new)

Final score for writes: 2265

Final score for reads : 203668

* BIOs are processed by two worker pools, each having a set of threads bound to a particular CPU. Read requests need to be decrypted, while write requests need to be encrypted. Having a separate worker pool for read and write requests should provide more fairness. Requests are scheduled to the workers using round-robin, and "struct bio" is used to chain "requests" to be processed by worker threads. Read workers need no further memory to be allocated in order to decrypt the blocks. The write workers use a shared mpipe as before, as we need to copy the write buffer before encrypting it.

* Currently, dm_target_crypt_ng only supports AES-CBC and AES-XTS. Twofish and Serpent are not supported. They are said to be more secure, but also slower and do not have hardware support. It should be easy to bring them back into crypto_ciphers.{c,h}.

* If you want to try out the new module, add the following line to /boot/loader.conf:

dm_target_crypt_ng_load=YES

This might not work with "swapon" as it tries to manually load "dm_target_crypt".

* My plan is to make "dm_target_crypt_ng" the default and remove the old "dm_target_crypt" after more intensive testing and feedback."

Since that initial commit a few days ago there has been additional dm_target_crypt_ng patches being merged. Follow-up patches have refactored the crypto ciphers, improved the crypto cipher API, and introducing Twofish/Serpent CBC/XTS ciphers. Some nice improvements for those wanting to make use of disk encryption with DragonFlyBSD.

As it's been over two years since the previous release of this operating system, [2]DragonFlyBSD 6.4 , hopefully the next release will get wrapped up soon with this next-generation DM-crypt target and the many other enhancements that have queued up over this time.



[1] https://gitweb.dragonflybsd.org/dragonfly.git/commit/14e6c73d4c479e4ab26571490758da27da5cbbad

[2] https://www.phoronix.com/news/DragonFlyBSD-6.4-Released



jaypatelani

Love is the only game that is not called on account of darkness.
-- M. Hirschfield