How to verify hardware acceleration is enabled for disk encryption

tanlu · June 16, 2026, 1:09am

Hello!

I’ve enabled disk encryption on an external NVMe SSD on my AGX Orin 64GB, following the instructions from Disk Encryption — NVIDIA Jetson Linux Developer Guide 1 documentation . How can I verify that hardware acceleration is actually being used?

My LUKS configuration:

# cryptsetup luksDump /dev/nvme0n1p1

LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           <REDACTED>
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]

Keyslots:
0: luks2
Key:        512 bits
Priority:   normal
Cipher:     aes-xts-plain64
Cipher key: 512 bits
PBKDF:      argon2id

Here’s what I’ve checked so far:

# grep -B1 -A10 -iE 'xts' /proc/crypto

name         : xts(aes)
driver       : xts-aes-tegra
module       : tegra_se
priority     : 500
refcnt       : 1
selftest     : passed
internal     : no
type         : skcipher
async        : no
blocksize    : 16
min keysize  : 32
max keysize  : 64

name         : __xts(aes)
driver       : cryptd(__xts-aes-ce)
module       : kernel
priority     : 350
refcnt       : 2
selftest     : passed
internal     : yes
type         : skcipher
async        : yes
blocksize    : 16
min keysize  : 32
max keysize  : 64

I can see the xts-aes-tegra driver from the tegra_se module is present.

My questions:

Are there any logs or commands that can confirm dm-crypt is actually using the tegra-se driver (rather than falling back to the software/CE implementation)?
I also see these crypto kernel threads:
# ps aux | grep crypto
823 root 0:00 [15820000.crypto]
824 root 0:00 [15840000.crypto]

CPU usage stays very low even during heavy read/write operations. Is this low CPU usage a reliable indicator that hardware acceleration is engaged, or could it be misleading?

Thanks in advance!

carolyuu · June 16, 2026, 4:03am

— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —

Based on the provided context, I could not find clear support for that in the provided Jetson Orin NX documentation. However, I can provide some general information about disk encryption and hardware acceleration.

The provided context does not specifically mention how to verify that hardware acceleration is being used for disk encryption on the Jetson Orin NX. However, it does mention that the xts-aes-tegra driver is present, which suggests that the tegra-se module is being used for encryption.

Regarding the low CPU usage, it is not a reliable indicator that hardware acceleration is engaged. CPU usage can be influenced by many factors, and low CPU usage does not necessarily mean that hardware acceleration is being used.

To verify that hardware acceleration is being used, you may want to check the kernel logs or system messages for any information related to disk encryption and hardware acceleration. You can also try using tools such as dmsetup or cryptsetup to check the status of the encrypted device and see if it is using the tegra-se driver.

Here is an example of how you can use dmsetup to check the status of the encrypted device:

# dmsetup status

This command will show you the status of the device mapper, including any encrypted devices. You can also use cryptsetup to check the status of the encrypted device:

# cryptsetup status /dev/nvme0n1p1

This command will show you the status of the encrypted device, including any information about the encryption algorithm and key being used.

I hope this information is helpful. If you have any further questions, please let me know.

— We support team will also look into your issue to have further suggestions soon. please stay tuned. —

tanlu · June 16, 2026, 5:27pm

Output from cryptsetup status

type: LUKS2
cipher: aes-xts-plain64
keysize: 512 bits
key location: keyring
device: /dev/nvme0n1p1
sector size: 512
offset: 32768 sectors
size: 2000373760 sectors
mode: read/write

I did some profiling with perf and it looks like we’re hitting ARMv8 CE instructions for XTS encryption.

perf-report.txt (5.2 MB)

                           --5.48%--kcryptd_crypt
                                     |
                                      --5.27%--crypt_convert.isra.0
                                                |
                                                 --4.58%--crypto_skcipher_encrypt
                                                           |
                                                            --4.50%--simd_skcipher_encrypt
                                                                      |
                                                                       --4.32%--crypto_skcipher_encrypt
                                                                                 |
                                                                                  --4.19%--xts_encrypt
                                                                                            |
                                                                                            |--1.61%--aes_encrypt_block4x
                                                                                            |
                                                                                            |--1.04%--ce_aes_xts_encrypt
                                                                                            |
                                                                                             --0.66%--kernel_neon_end
                                                                                                       |
                                                                                                        --0.65%--put_cpu_fpsimd_context

Can you confirm if this is intended behavior under these circumstances? Why is the hardware security engine (tegra-se) not kicking in?

JerryChang · June 24, 2026, 7:18am

hello tanlu,

you may execute the command below to check the crypto algorithms that can leverage HW SE engine with Linux crypto framework. $ cat /proc/crypto | grep tegra

FYI, we use “aes-xts-plain64” as the disk encryption crypto algorithm.
you may observe the kernel thread “15820000.se-eng” via top, the thread is the SE driver to handle AES encryption/decryption.

tanlu · July 6, 2026, 10:51pm

Here is the output

# cat /proc/crypto | grep tegra
driver       : tegra-se-hmac-sha512
module       : tegra_se
driver       : tegra-se-hmac-sha384
module       : tegra_se
driver       : tegra-se-hmac-sha256
module       : tegra_se
driver       : tegra-se-hmac-sha224
module       : tegra_se
driver       : tegra-se-sha3-512
module       : tegra_se
driver       : tegra-se-sha3-384
module       : tegra_se
driver       : tegra-se-sha3-256
module       : tegra_se
driver       : tegra-se-sha3-224
module       : tegra_se
driver       : tegra-se-sha512
module       : tegra_se
driver       : tegra-se-sha384
module       : tegra_se
driver       : tegra-se-sha256
module       : tegra_se
driver       : tegra-se-sha224
module       : tegra_se
driver       : tegra-se-sha1
module       : tegra_se
driver       : tegra-se-cmac
module       : tegra_se
driver       : ccm-aes-tegra
module       : tegra_se
driver       : gcm-aes-tegra
module       : tegra_se
driver       : xts-aes-tegra
module       : tegra_se
driver       : ctr-aes-tegra
module       : tegra_se
driver       : ecb-aes-tegra
module       : tegra_se
driver       : cbc-aes-tegra
module       : tegra_se

tanlu · July 6, 2026, 10:56pm

@JerryChang What’s the expected CPU usage for the security engine kernel thread?

I tried doing a 5GB file write using dd, but the CPU load for the kernel thread always stay at 0%.

##### Ran 5GB file write test ##### 

# dd if=/dev/zero of=/mnt/ssd/test bs=1M count=5120 conv=fsync5120+0 records in5120+0 records out5368709120 bytes (5.4 GB, 5.0 GiB) copied, 5.51263 s, 974 MB/s

##### Monitoring CPU usage from terminal 2 ##### 

# /usr/bin# PID=$(ps aux | awk '/\[15820000\.crypto\]/ {print $1}'); top -b -d 1 | awk -v p="$PID" '$1==p'
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]
  817     2 root     SW       0   0%   0% [15820000.crypto]

JerryChang · July 7, 2026, 4:56am

hello tanlu,

0% CPU for the SE engine thread can be normal, it should not be used as proof that SE is unused. monitoring CPU usage it only accounts CPU time spent in request dispatch/copy/wait handling, not SE hardware utilization.

tanlu · July 8, 2026, 1:09am

@JerryChang

I tried running perf while generating a sustained write load to the encrypted mount and profile, e.g.:

dd if=/dev/zero of=/mnt/ssd/testfile bs=1M count=5120 oflag=direct conv=fsync status=progress

and then

My observation as mentioned above is that the AES work runs on the CPU (aes_ce / __xts / xts_* symbols hot; kcryptd unbound kworkers busy; elevated %sys), while the Tegra SE is idle — despite xts-aes-tegra having the higher priority (500 > 300).

Is there any other way to prove that the SE engine is engaged for disk encryption/decryption? Any debug logs we can turn on?

JerryChang · July 8, 2026, 5:44am

hello tanlu,

in general, when the tegra_se kernel module is loaded, it registers AES algorithms with higher priority than CPU AES-CE, and dm-crypt uses the Tegra Security Engine for disk encryption/decryption by default.

you may also check dd I/O goes through dm-crypt and reaches the encrypted backing partition, i.e. APP_ENC.

Topic		Replies	Views
Security Engine is Offline Jetson AGX Orin security-acceleration	3	415	June 2, 2024
Full disk encryption hardware acceleration? Jetson TX2 security	3	428	July 3, 2024
Disk encryption exhibits High CPU usage in JetPack 5.1.2 (using Orin AGX) Jetson AGX Orin security	2	131	February 25, 2025
Encryption/ decryption speeds on Orin NX Jetson Orin NX	7	290	April 28, 2025
Hi all, I need to verify the speed diffrence in disk encryption. I want to disable the tegra-crypto driver on NVIDIA Orin NX. How can I do that? Jetson Orin NX security	1	58	February 23, 2026
Data encryption on AGX Jetson Orin Jetson AGX Orin security , flash	14	583	September 16, 2024
Encrypted ssd nvme on Jetson Orin NX Jetson Orin NX security	14	440	November 28, 2025
Orin AGX NVMe disk encryption Jetson AGX Orin security	6	1495	August 17, 2023
Dynamic Nvme Disk encryption Jetson Orin NX security	9	223	December 22, 2025
Disk encryption on nvme and mash flashing Jetson agx orin devolpment kit Jetson AGX Orin security	9	116	April 7, 2026

How to verify hardware acceleration is enabled for disk encryption

Related topics