Arch Linux

BeardPower

Member

Registered: 2016-12-30

Posts: 1

cryptsetup - some commands never complete - hashes do not work

Hi everyone,

I'm new to arch, so I ran the iso from an USB key to test it out: Current Release: 2016.12.01

uname -a
Linux archiso 4.8.11-1-ARCH #1 SMP PREEMPT Sun Nov 27 09:26:14 CET 2016 x86_64 GNU/Linux

Goal:
create some Luks encrypted device with a remote header

Steps:

truncate -s 2M header.img
cryptsetup luksFormat /dev/sdX --header header.img

Outcome:
after entering the passphrase (and validation), the command hangs forever, eating up 100% of a CPU cycles.

So the benchmark was run, to check if performance is just weak:

cryptsetup --debug benchmark

# cryptsetup 1.7.3 processing "cryptsetup --debug benchmark"
# Running command benchmark.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Tests are approximate using memory only (no storage IO).
# Crypto backend (gcrypt 1.7.3) initialized in cryptsetup library version 1.7.3.
# Detected kernel Linux 4.8.11-1-ARCH x86_64.

Nothing more is printed out. CPU load 100%.

Checking the hashes:

cryptsetup --debug --hash sha1 benchmark

# cryptsetup 1.7.3 processing "cryptsetup --debug --hash sha1 benchmark"
# Running command benchmark.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Tests are approximate using memory only (no storage IO).
# Crypto backend (gcrypt 1.7.3) initialized in cryptsetup library version 1.7.3.
# Detected kernel Linux 4.8.11-1-ARCH x86_64.
#  Algorithm | Key |  Encryption |  Decryption

Nothing more is printed out. CPU load 100%.

Another run to check the ciphers:

cryptsetup --debug --cipher aes-xts benchmark

# cryptsetup 1.7.3 processing "cryptsetup --debug --cipher aes-xts benchmark"
# Running command benchmark.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Tests are approximate using memory only (no storage IO).
# Crypto backend (gcrypt 1.7.3) initialized in cryptsetup library version 1.7.3.
# Detected kernel Linux 4.8.11-1-ARCH x86_64.
#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b   596.0 MiB/s   608.7 MiB/s
Command successful.

It seems that the PBKDF2 functions are blocking and so is luksFormat, because it's using these. Running arch in a VM works totally fine. No problems whatsoever.

Tests with archlinux-2016.10.01-dual.iso has similar behavior. It only works sporadically (did not work at the first boot, but after 2-3 reboots).
I also tested cryptsetup with other distros (e.g. Linux Mint) from a USB key to make sure and there were no issues.

What also makes me wondering, is the fact, that the ciphers have such a degraded performance on arch compared to other distros (in my recent test case Linux Mint). It seems, that there is some issue with the aesni_intel module.

lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                12
On-line CPU(s) list:   0-11
Thread(s) per core:    2
Core(s) per socket:    6
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 45
Model name:            Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz
Stepping:              7
CPU MHz:               3200.445
CPU max MHz:           3800.0000
CPU min MHz:           1200.0000
BogoMIPS:              6403.59
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              12288K
NUMA node0 CPU(s):     0-11
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse 

sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf 

eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt 

tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts

I made sure the aesni_intel model was loaded.

lsmod | grep -i aes

aesni_intel           167936  0
aes_x86_64             20480  1 aesni_intel
lrw                    16384  1 aesni_intel
glue_helper            16384  1 aesni_intel
ablk_helper            16384  1 aesni_intel
cryptd                 20480  3 ablk_helper,ghash_clmulni_intel,aesni_intel

Performance of aes-xts on arch:

#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b   596.0 MiB/s   608.7 MiB/s

Performance of aes-xts on Linux Mint 18.1 (Linux mint 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64
x86_64 GNU/Linux). It's using cryptsetup version 1.6.6 with the gcrypt 1.6.5 backend.

#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b  1888.5 MiB/s  1757.8 MiB/s 

I also made a test after unloading the aesni_intel module:

#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b    75.0 MiB/s    76.8 MiB/s

Performance in the VM (with aesni_intel module loaded)
arch:

#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b  1651.3 MiB/s  1698.4 MiB/s

Linux Mint:

#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b  1621.7 MiB/s  1662.0 MiB/s

So in the VM arch is faster.

Any ideas what could be the problem or how I could investigate the issues further?

Thanks for any input!