[Cryptography] Speeding up Linux disk encryption

Dan McDonald danmcd at kebe.com
Thu Apr 1 01:30:40 EDT 2021


On Mar 31, 2021, at 4:58 PM, Arnold Reinhold via cryptography <cryptography at metzdowd.com> wrote:
> 
> I found this interesting article from Cloudfare on their efforts to speed up Linux disk encryption:
> 
> https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
> 
> The level of complexity seems concerning given the increased opportunity for error. One obstacle that struck me is the the Intel AES-NI hardware instructions cannot be used within interrupt service routines because the Intel instructions use the floating point registers to store the round constants and Linux interrupts do not save those registers for performance reasons.

It isn't just Linux.

> Also floating point operations can throw their own interrupts, which could be problematic. (One is advised not to use floating point in Linux interrupt service routines for these reasons.) Does ARM AES hardware have similar problems? RISC-V?

I'd be VERY interested to know how other HW with AES acceleration handles these situations.

From the article:

> Our solution to address the above was to create another somewhat "smart" Crypto API module. This module is synchronous and does not roll its own crypto, but is just a "router" of encryption requests:
> 
> 	• if we can use the FPU (and thus AES-NI) in the current execution context, we just forward the encryption request to the faster, "internal" __xts-aes-aesni implementation (and we can use it here, because now we are part of the Crypto API)
> 	• otherwise, we just forward the encryption request to the slower, generic C-based xts(ecb(aes-generic)) implementation

The FP registers essentially DOUBLE OR MORE the register-save time on amd64 environments during a context-switch.

In illumos, if AES-NI is available, we set the thread to NOT be preemptable during AES-NI operations.  Source here:

	http://src.illumos.org/source/xref/illumos-gate/usr/src/common/crypto/aes/aes_impl.c

and look around for KPREEMPT_{DIS,EN}ABLE.  Basically the scheduler cannot context-switch the thread in between KPREEMPT_{DIS,EN}ABLE blocks.

Dan



More information about the cryptography mailing list