dm-inlinecrypt: add target for inline block device encryption

From: Eric Biggers <[email protected]>

Add a new device-mapper target "dm-inlinecrypt" that is similar to dm-crypt but uses the blk-crypto API instead of the regular crypto API. This allows it to take advantage of inline encryption hardware such as that commonly built into UFS host controllers.

The table syntax matches dm-crypt's, but for now only a stripped-down set of parameters is supported. For example, for now AES-256-XTS is the only supported cipher.

dm-inlinecrypt is based on Android's dm-default-key with the controversial passthrough support removed. Note that due to the removal of passthrough support, use of dm-inlinecrypt in combination with fscrypt causes double encryption of file contents (similar to dm-crypt + fscrypt), with the fscrypt layer not being able to use the inline encryption hardware. This makes dm-inlinecrypt unusable on systems such as Android that use fscrypt and where a more optimized approach is needed. It is however suitable as a replacement for dm-crypt.

---

This is yet another proposal for dm-inlinecrypt, this one resulting from the conversation at
https://lore.kernel.org/linux-block/[email protected]/T/#u.
This brings in the work that was already done in Android's dm-default-key but drops the passthrough support, as it doesn't seem like that will go anywhere upstream anytime soon. This makes the proposal suitable as a replacement for dm-crypt only.

 block/blk-crypto.c          |   3 +
 drivers/md/Kconfig          |  10 +
 drivers/md/Makefile         |   1 +
 drivers/md/dm-inlinecrypt.c | 415 ++++++++++++++++++++++++++++++++++++
 4 files changed, 429 insertions(+)
 create mode 100644 drivers/md/dm-inlinecrypt.c

index 4d760b092deb..5a121b1292f9 100644
@@ -104,10 +104,11 @@ void bio_crypt_set_ctx(struct bio *bio, const struct blk_crypto_key *key,
 	bc->bc_key = key;
 	memcpy(bc->bc_dun, dun, sizeof(bc->bc_dun));
 
 	bio->bi_crypt_context = bc;
 }
+EXPORT_SYMBOL_GPL(bio_crypt_set_ctx);
 
 void __bio_crypt_free_ctx(struct bio *bio)
 {
 	mempool_free(bio->bi_crypt_context, bio_crypt_ctx_pool);
 	bio->bi_crypt_context = NULL;

@@ -354,10 +355,11 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key,
 	blk_key->size = mode->keysize;
 	memcpy(blk_key->raw, raw_key, mode->keysize);
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(blk_crypto_init_key);
 
 bool blk_crypto_config_supported_natively(struct block_device *bdev,
 					  const struct blk_crypto_config *cfg)
 {
 	return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile,

@@ -396,10 +398,11 @@ int blk_crypto_start_using_key(struct block_device *bdev,
 {
 	if (blk_crypto_config_supported_natively(bdev, &key->crypto_cfg))
 		return 0;
 	return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode);
 }
+EXPORT_SYMBOL_GPL(blk_crypto_start_using_key);
 
 /**
  * blk_crypto_evict_key() - Evict a blk_crypto_key from a block_device
  * @bdev: a block_device on which I/O using the key may have been done
  * @key: the key to evict

index 1e9db8e4acdf..caed60097a21 100644
@@ -268,10 +268,20 @@ config DM_CRYPT
 	  To compile this code as a module, choose M here: the module will
 	  be called dm-crypt.
 
 	  If unsure, say N.
 
+config DM_INLINECRYPT
+	tristate "Inline encryption target support"
+	depends on BLK_DEV_DM
+	depends on BLK_INLINE_ENCRYPTION
+	help
+	  This device-mapper target is similar to dm-crypt, but it uses the
+	  blk-crypto API instead of the regular crypto API. This allows it to
+	  take advantage of inline encryption hardware such as that commonly
+	  built into UFS host controllers.
+
 config DM_SNAPSHOT
        tristate "Snapshot target"
        depends on BLK_DEV_DM
        select DM_BUFIO
 	help

index 476a214e4bdc..6e44ff32b8af 100644
@@ -49,10 +49,11 @@ obj-$(CONFIG_BLK_DEV_DM)	+= dm-mod.o
 obj-$(CONFIG_BLK_DEV_DM_BUILTIN) += dm-builtin.o
 obj-$(CONFIG_DM_UNSTRIPED)	+= dm-unstripe.o
 obj-$(CONFIG_DM_BUFIO)		+= dm-bufio.o
 obj-$(CONFIG_DM_BIO_PRISON)	+= dm-bio-prison.o
 obj-$(CONFIG_DM_CRYPT)		+= dm-crypt.o
+obj-$(CONFIG_DM_INLINECRYPT)	+= dm-inlinecrypt.o
 obj-$(CONFIG_DM_DELAY)		+= dm-delay.o
 obj-$(CONFIG_DM_DUST)		+= dm-dust.o
 obj-$(CONFIG_DM_FLAKEY)		+= dm-flakey.o
 obj-$(CONFIG_DM_MULTIPATH)	+= dm-multipath.o dm-round-robin.o
 obj-$(CONFIG_DM_MULTIPATH_QL)	+= dm-queue-length.o

base-commit: e32cde8d2bd7d251a8f9b434143977ddf13dcec6

2.46.2

Maybe I'm stepping into a mine-field here, but if this simply uses blk-crypto to accellerate a subset of dm-crypt, why isn't dm-crypt simply enhanced to use blk-crypto when available? compatible,

Please split the exports in a separate subsystem into a separate prep patch, documenting why it makes sense to have these as exported APIs.

Milan Broz (cryptsetup maintainer) has said that he prefers a separate dm target. See
https://lore.kernel.org/dm-devel/[email protected]/

That was a couple years ago though, and this discussion seems to have gone around in a circle. Maybe things have changed.

A dm-crypt extension sounds fine to me too, though keep in mind there will eventually be inline crypto exclusive features such as hardware-wrapped keys.

- Eric

There was another discussion recently. I also discussed this with Mikulas as DM maintainer, and we agreed this is the best way.

Extending dm-crypt is possible, but the dm-crypt threat model should not allow pushing plaintext down the level.
(I am currently investigating several issues with Opal hw encryption that just cannot happen with sw dm-crypt. We opened can of worms supporting it in LUKS. :)

Actually, I like the inline encryption logic (and the sw fallback), just I would prefer we clearly separate the code here (and dm-crypt is already complicated enough).

Milan

As should any other stackable crypto driver, so that's not an argument per se. Allowing to bypass encryption in a lower layer is simply broken, no matter what you call the target.

Now code complexity is an absolute valid argument. I think it should be weighted very carefully vs a confusing user interface that requires the user to know if there is hardware acceleration or not.

I am talking from the security point of view. Now, dm-crypt does not trust storage devices. Storage devices will never see plaintext (or key). With inline crypto, it needs to see both.

My goal is to mitigate these risks completely with dm-crypt, while clearly saying dm-inlinecrypt will have a different threat model.

(Yes, if inline crypto is used through crypto API, we have the same problem, but you can mitigate it by turning off specific crypto modules.)

You are right that such a system is broken, but it is too late if it leaks.

I see several self-encryption hardware where it was so broken that vendors basically say, "use sw crypto" but this will not stop users from using it in a broken state.

Milan

With inline crypto as implemented right now the actual storage device does not see the plaintext and key, only the storage controller that is part of the SOC that Linux runs on.

That same could be done by requiring an explicit opt-in for using inline crypto. But yes, at that point just using a different target should not be a major inconvenience.

Well, with the crazy mess that the TCG storage specs are the quality of implementation of key management or even crypto algorithms that is everything but unexpected. One important feature of inline crypto engines is that they can't just do key management or pick their algorithms and you can always validate the ciphertext vs that done by software, something that can't work with the broken Opal-like full disk encryption model.

Anyway, not wanting to second guess you here, just throwing in my 2 cents.