LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices


Reply
  Search this Thread
Old 07-30-2021, 01:58 PM   #1
foxite
LQ Newbie
 
Registered: Jul 2021
Posts: 4

Rep: Reputation: Disabled
How to enable xts(ecb(aes-generic))


xts(ecb(aes-generic)) is not present in /proc/crypto, but I need it to fix a serious problem with my computer. How can I enable it?

Background, if you're curious why I need such a specific thing:

Quote:
Up until last month I have been using arch linux on an unencrypted drive. Since then, my drives have been encrypted using dm-crypt.

Soon after I implemented encryption, I noticed a problem: whenever a process writes a lot of data to the disk, my system grinds to a halt. After some research, I found out that Cloudflare had the exact same problem, and they wrote a kernel patch to fix it. You can read more about that here. https://blog.cloudflare.com/speeding...sk-encryption/

Their patch adds a cipher which acts as a proxy to two other ciphers. One is aes-ni which uses hardware acceleration, the other is aes-generic -- specifically, xts(ecb(aes-generic)) -- which is slower but has the benefit of not requiring the use of a CPU register which is not safe to use in an interrupt context. Cloudflare's cipher decides which one to use based on whether or not the current context is an interrupt context.

In the article, they demonstrate the effectiveness of their patch by creating an encrypted ramdisk and benchmarking it. With the standard cipher, the problem is apparent. When they execute this command:

Code:
sudo dmsetup table encrypted-ram0 --showkeys | sed 's/aes-xts-plain64/capi:xts-aes-xtsproxy-plain64/' | sed 's/$/ 1 force_inline/' | sudo dmsetup reload encrypted-ram0
Which tells dm-crypt to use Cloudflare's cipher instead, after benchmarking the encrypted ramdisk again, the problem is completely gone.

So I downloaded the kernel source code, applied Cloudflare's patch, and compiled the kernel and rebooted using it. I retrace Cloudflare's steps and create an encrypted ramdisk. However, when I try to execute the above command, I get this error:

Code:
device-mapper: reload ioctl on encrypted-ram0  failed: Invalid argument
Command failed.
Some deeper investigation has shown that xts(ecb(aes-generic)) is not present inside /proc/crypto, while Cloudflare does have access to it in their kernels, which appears to be linux-lts, which is what I'm using. Cloudflare makes no mention of the need to enable this cipher in their article.

I'm pretty much stumped as to why I am missing this cipher, the one person who I know personally that also uses linux does not have the cipher either, and I don't know where to look for how to enable it. So I turn to linuxquestions.

Last edited by foxite; 07-30-2021 at 02:34 PM.
 
Old 08-25-2021, 09:48 AM   #2
foxite
LQ Newbie
 
Registered: Jul 2021
Posts: 4

Original Poster
Rep: Reputation: Disabled
After about a month of not making any progress on this issue it has finally become clear to me that the "Invalid argument" error I receive has nothing to do with xts(ecb(aes-generic)) not being loaded, as it becomes loaded automatically when I run a command such as this:

Code:
sudo cryptsetup luksFormat /dev/ram0 --header crypthdr.img --cipher capi:xts(ecb(aes-generic))-plain64
Which seems to imply that Cloudflare's xtsproxy is supposed to cause xts(ecb(aes-generic)) to become loaded automatically, and it isn't even making it to that point before an error occurs.

I'm on my laptop right now, and I do not have access to the compiled kernel with the patches applied, and I have no time to compile it. In about two hours I am going to test what I think should be the right command:

Code:
sudo dmsetup table encrypted-ram0 --showkeys | sed 's/aes-xts-plain64/xts-aes-xtsproxy-plain64/' | sed 's/$/ 1 force_inline/' | sudo dmsetup reload encrypted-ram0
Note the lack of "capi:" in this command.

I will update this post with my findings.
 
Old 09-20-2021, 12:50 PM   #3
foxite
LQ Newbie
 
Registered: Jul 2021
Posts: 4

Original Poster
Rep: Reputation: Disabled
It has become apparent that I was on the wrong track for quite a while, but now I've actually been able to reproduce something that Cloudflare wrote. I'm keeping this thread updated so that anyone who has the same problems when trying to reproduce Cloudflare's article, will be able to get some use out of this thread. In other words, I'm trying to avoid an xkcd-979 problem.

So after several more weeks with no progress I was finally able to get a major speed increase on an encrypted ramdisk. The main problem was because Cloudflare runs dm-setup table followed by two sed commands, however the second sed command makes the assumption that you don't already have an argument at the end of your dm-setup table. In my case I did have one (sector_size:4096) which is why it didn't work.

Furthermore, it adds "force_inline" which doesn't exist in the current kernel, as Cloudflare's patch that was used throughout the article, was modified before being merged into the kernel tree. There's now two flags, no_read_workqueue and no_write_workqueue.

Suppose your dm-setup table looks like this:

0 32000000 crypt capi:xts-aes-xtsproxy-plain64 b9d2f1150716028143a06f6cbc624a25e1f9d75e2b5a08a3808f37b0f51057d4d1a4ebf6e47a8ab19e94e8baaa2784732034 63109a209a3dda5920849e4b4af3 0 1:0 0 1 sector_size:4096

You need to change it to this:

0 32000000 crypt capi:xts-aes-xtsproxy-plain64 b9d2f1150716028143a06f6cbc624a25e1f9d75e2b5a08a3808f37b0f51057d4d1a4ebf6e47a8ab19e94e8baaa2784732034 63109a209a3dda5920849e4b4af3 0 1:0 0 3 sector_size:4096 no_read_workqueue no_write_workqueue

Preferably by echoing the whole thing directly into dmsetup reload.

If you're running fio while doing this you should observe an immediate speed increase, mine went up by a factor of 2.5.

I'm going to try this on my root dm-crypt device next, and see what happens.
 
Old 09-21-2021, 10:35 AM   #4
foxite
LQ Newbie
 
Registered: Jul 2021
Posts: 4

Original Poster
Rep: Reputation: Disabled
It has come to my attention that this whole journey could have been avoided if I had just noticed this section on archwiki which was there since the beginning: https://wiki.archlinux.org/title/Dm-...D)_performance

Applying these flags to the root device fixes all the problems I was having. Xtsproxy seems to be unnecessary and the wiki article makes no mention of it.

I'd edit the OP to include this fact, however I seem to be unable to edit all but my last post in this thread.

Last edited by foxite; 09-21-2021 at 10:36 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Encryption library on Linux provides AES implementation based on cpu aes instruction rainman1985_2010 Programming 3 07-03-2015 05:34 PM
LUKS: xts-plain vs xts-essiv? phoenix_precedent Linux - Security 13 12-23-2014 02:31 AM
alg: No test for ecb(cipher_null) (ecb-cipher_null) What is this? netstv Linux - Kernel 0 11-02-2010 06:03 PM
dm-crypt aes-xts-plain64 vs aes-cbc-essiv for volumes > 2TiB Molly Linux - Security 1 09-13-2010 05:24 PM
using aes-i586 instead of just aes whysyn Linux - Security 0 03-07-2007 03:47 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel

All times are GMT -5. The time now is 09:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration