kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +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
treewide: refresh kmalloc_obj() conversions This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org>
2026-09-02 15:31:14 -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
blk-crypto: Allow control over whether hardware is used fscrypt uses inline encryption hardware only when the "inlinecrypt" mount option is given. I'd like to keep that behavior even after standardizing on the blk-crypto API for file contents encryption. That is, the default should continue to be the well-tested CPU-based encryption code, and the use of inline encryption hardware should continue to be an opt-in feature for systems where it's beneficial and has been fully validated (including verifying ciphertext correctness). To support this use case, extend blk_crypto_config with a new flag BLK_CRYPTO_CFG_ALLOW_HW. For now it's always set. Later commits will change that. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-12 22:36:54 -04: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