37 ms·

I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block ciph

I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block cipher mode, but it shouldn't be much slower. So if implemented correctly, encrypted swap should not slow you down vs unencrypted swap. If in your setup encrypted swap is much slower than unencrypted swap, it's a bug in the kernel crypto and it should be fixed.

noinsight 9y ago
Actually, Samsung 960 Pros are fast enough that encryption becomes a bottleneck, at least on my Xeon E5-2620v4. You can test it yourself with `cryptsetup benchmark`: # cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 1874.2 MiB/s 2042.6 MiB/s I was surprised and it made me doubt whether it's using AES-NI at all, but then again it's not an issue in practice.
- wolf550e 9y ago
  cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 2266.2 MiB/s 2273.8 MiB/s perf says 21.86% cryptsetup [aesni_intel] [k] _aesni_dec4 19.83% cryptsetup [aesni_intel] [k] _aesni_enc4 17.80% cryptsetup [aesni_intel] [k] aesni_xts_crypt8 13.73% cryptsetup [kernel] [k] copy_user_generic_unrolled 2.20% cryptsetup [kernel] [k] get_page_from_freelist 1.86% cryptsetup [glue_helper] [k] glue_xts_crypt_128bit 1.53% cryptsetup [kernel] [k] put_page 1.36% cryptsetup [kernel] [k] blkcipher_walk_done so it's using the code from: https://github.com/torvalds/linux/blob/master/arch/x86/crypto/aesni-intel_asm.S#L2848 https://github.com/torvalds/linux/blob/master/arch/x86/crypt... I don't know if using AVX would speed it up. openssl is faster (openssl speed -evp aes-256-gcm and aes-256-xts).
kbenson 9y ago
Even if a modern CPU can to do, the question is whether on a stock distro kernel they will do that. I could see the default kernels not being compiled with the extensions that may allow that speed for compatibility purposes. Then again, I remember when distros often shipped different i386, i586 and i686 kernels, and when Red Hat switched away from i386 as the default kernel (which might be a lot more recent than you think, if you weren't thinking of all the cheap i386 devices it was still working on in the early 2000's). Then, even if the stock kernel does support it through a kernel module, the question is whether that module was loaded. Finally, from looking at an Intel/AMD AES intructions compatibility list[1], not all processors as of even a couple years ago supported AES instructions (notably, it appears Intel used it to differentiate the i3 line from the more powerful ones).. 1: https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_...
ahh 9y ago
I'm uncertain if it's safe to use AESENC and friends in kernel mode in Freebsd. A number of kernels can't safely use e.g. FPU registers in-kernel and aesni operates exclusively on SSE state.
- loeg 9y ago
  It's safe. The FreeBSD kernel is capable of preserving user FPU state when kernel threads (e.g., aesni(4)) need to use FPU registers.

noinsight 9y ago

Actually, Samsung 960 Pros are fast enough that encryption becomes a bottleneck, at least on my Xeon E5-2620v4. You can test it yourself with `cryptsetup benchmark`: # cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 1874.2 MiB/s 2042.6 MiB/s I was surprised and it made me doubt whether it's using AES-NI at all, but then again it's not an issue in practice.

wolf550e 9y ago
cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 2266.2 MiB/s 2273.8 MiB/s perf says 21.86% cryptsetup [aesni_intel] [k] _aesni_dec4 19.83% cryptsetup [aesni_intel] [k] _aesni_enc4 17.80% cryptsetup [aesni_intel] [k] aesni_xts_crypt8 13.73% cryptsetup [kernel] [k] copy_user_generic_unrolled 2.20% cryptsetup [kernel] [k] get_page_from_freelist 1.86% cryptsetup [glue_helper] [k] glue_xts_crypt_128bit 1.53% cryptsetup [kernel] [k] put_page 1.36% cryptsetup [kernel] [k] blkcipher_walk_done so it's using the code from: https://github.com/torvalds/linux/blob/master/arch/x86/crypto/aesni-intel_asm.S#L2848 https://github.com/torvalds/linux/blob/master/arch/x86/crypt... I don't know if using AVX would speed it up. openssl is faster (openssl speed -evp aes-256-gcm and aes-256-xts).

kbenson 9y ago

Even if a modern CPU can to do, the question is whether on a stock distro kernel they will do that. I could see the default kernels not being compiled with the extensions that may allow that speed for compatibility purposes. Then again, I remember when distros often shipped different i386, i586 and i686 kernels, and when Red Hat switched away from i386 as the default kernel (which might be a lot more recent than you think, if you weren't thinking of all the cheap i386 devices it was still working on in the early 2000's). Then, even if the stock kernel does support it through a kernel module, the question is whether that module was loaded. Finally, from looking at an Intel/AMD AES intructions compatibility list[1], not all processors as of even a couple years ago supported AES instructions (notably, it appears Intel used it to differentiate the i3 line from the more powerful ones).. 1: https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_...

ahh 9y ago

I'm uncertain if it's safe to use AESENC and friends in kernel mode in Freebsd. A number of kernels can't safely use e.g. FPU registers in-kernel and aesni operates exclusively on SSE state.

loeg 9y ago
It's safe. The FreeBSD kernel is capable of preserving user FPU state when kernel threads (e.g., aesni(4)) need to use FPU registers.