kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-08 18:57:22 +00:00
Code Issues Releases Packages Activity
linux/drivers/md/dm-inlinecrypt.c

620 lines
16 KiB
Raw Permalink Normal View History

dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: Fix an error handling path in inlinecrypt_ctr() All error handling paths, except but this one, branch to the 'bad' label in the error handling path. If not done, there is a memory leak and some sensitive data may be kept around. So, fix this error path and also do the needed clean-up. Also, fix missing goto in the "Wrong alignment of iv_offset sector" path. Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-06-20 21:33:03 +02:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: Fix an error handling path in inlinecrypt_ctr() All error handling paths, except but this one, branch to the 'bad' label in the error handling path. If not done, there is a memory leak and some sensitive data may be kept around. So, fix this error path and also do the needed clean-up. Also, fix missing goto in the "Wrong alignment of iv_offset sector" path. Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-06-20 21:33:03 +02:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00
dm-inlinecrypt: add support for hardware-wrapped keys Add support for hardware-wrapped encryption keys to the dm-inlinecrypt target. Introduce a new optional argument <key_type> to indicate whether the provided key is a raw key or a hardware-wrapped key. Based on this flag, the appropriate blk-crypto key type is selected when initializing the key. This allows dm-inlinecrypt to work with hardware that requires keys to be wrapped and managed by the underlying inline encryption engine. Update the target argument parsing accordingly and pass the key type to blk_crypto_init_key(). Documentation is also updated to reflect the new parameter and usage. Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption")
2026-05-25 05:13:48 -07:00
dm-inlinecrypt: add target for inline block device encryption 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. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-04-30 02:52:43 -07:00