1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking Benchmarking Platform
Phoromatic Test Orchestration

Intel AES-NI For Ubuntu Home Encryption

Michael Larabel

Published on 6 October 2011
Written by Michael Larabel
Page 1 of 7 - 6 Comments

Supported by modern Intel processors is the AES instruction set, which is designed to improve the speed of encryption and decryption on the CPU for AES, the Advanced Encryption Standard. Under Ubuntu Linux, even for supported hardware, the Intel AES-NI capability is not taken advantage of when enabling its data encryption feature. The Intel AES-NI support can be easily enabled, but what is the impact on performance? Here are some benchmarks.

Last month was an article entitled Ubuntu 11.10 Home Encryption Performance, which looked at the performance impact of using the home folder data encryption feature on the soon-to-be-released Ubuntu 11.10. For older hardware (Core 2 Duo with a mobile HDD) the impact of encrypting the user's home directory varied from 10~20% with heavy disk workloads. Using an Intel Sandy Bridge (Core i5) notebook with an Intel SSD caused less of an impact compared to no encryption at all. One of the emails that came in following last month's article was from Canonical's Dustin Kirkland.

Thanks for the update to the eCryptfs article. I'm pleased with the positive results, obviously.

One suggestion, for a followup... I've done just a little bit of sniff testing with the AES-NI acceleration that's built into some of the newer Intel chips (I think that HP with the i5 should have it).

eCryptfs uses the aes-ni acceleration if the module is loaded, but we (Ubuntu) are not loading that module by default. In my basic testing, I got some pretty inconclusive results, with the "acceleration" performing worse than non-accelerated in some cases. That could be due to a bad aes-ni implementation in the kernel? Or, perhaps it only really helps to offload a busy CPU.

In any case, I'd be interested in seeing a pair of benchmarks, one with your eCryptfs encrypted home and the stock (no aes-ni), and then a second set of tests after modprobing aesni-intel. Any interest in running those tests and hitting us up with the feedback?

Ask for interesting tests, and you shall receive. This article is looking at that the Intel AES-NI acceleration with Ubuntu eCryptfs home encryption. Testing was done with an Ubuntu 11.10 daily snapshot from 5 October 2011. For simplicity (and since the notebook was conveniently ready when arriving back from Oktoberfest), the same HP EliteBook with an Intel Core i5 2520M (Sandy Bridge) with Intel 160GB X-25 SSD was used for this AES-NI comparison.

The AES-NI instruction set has been supported by Intel CPUs going back to the Clarkdale/Arrandale family, but there are some exceptions in the models that support this new acceleration instruction set. The AES-NI support continues with Sandy Bridge (there are some unsupported models here too) and should be fully supported across all Ivy Bridge CPUs. The Core i5 2520M supports the AES New Instructions. The AES support can also be checked via the flags from /proc/cpuinfo under Linux. The Linux cryptography support can also be checked from /proc/crypto to ensure aesni-intel is loaded. With the default Phoronix Test Suite test location being within ~/.phoronix-test-suite/, all tests are being executed from within the encrypted home area.

The clean Ubuntu 11.10 snapshot was tested in its default configuration with home encryption enabled and then after loading the "aesni-intel" kernel module before logging into the encrypted user account. The Intel AES-NI instructions have been supported under Linux going back to early 2009.

As far as the slated improvements for AES-NI, Intel documentation provides the following:

The performance improvement expected with the use of AES-NI would depend on the applications and how much of the application time is spent in encryption and decryption. At the algorithm level, using AES-NI can provide significant speedup of AES. For non-parallel modes of AES operation such as CBC-encrypt AES-NI can provide a 2-3 fold gain in performance over a completely software approach. For parallelizable modes such as CBC-decrypt and CTR, AES-NI can provide a 10x improvement over software solutions.

Since the Sandy Bridge processor is already quite fast, this encryption comparison was done with all four threads enabled (two cores + Hyper Threading) and then when disabling the Hyper Threading and multi CPU support from the BIOS, so that only a single processing thread was available. The first of these results are with the stock settings (all four threads available). During the testing process, the Phoronix Test Suite also monitored the CPU usage automatically (by setting the MONITOR=cpu.usage environmental variable prior to starting the phoronix-test-suite client).

Latest Linux News
  1. Latest Rumor Pegs Microsoft Wanting To Buy AMD
  2. The Next-Gen Phoronix Site Experience Is Almost Ready
  3. Exciting Features Merged So Far For The Linux 4.2 Kernel
  4. Mesa 10.6.1 Brings A Bug-Fix For Dota 2 Reborn
  5. DragonFlyBSD 4.2 Released: Brings Improved Graphics & New Compiler
  6. Wine-Staging 1.7.46 Improves The OS X Experience
  7. The State & Complications Of Porting The Unity Editor To Linux
  8. Libreboot Now Supports An AMD/ASUS Motherboard
  9. SafeStack Merged Into LLVM To Protect Against Stack Buffer Overflow Attacks
  10. Terraria 1.3 Release Coming Later This Month With Many Improvements
Latest Articles & Reviews
  1. How KDE VDG Is Trying To Make Open-Source Software Beautiful
  2. Attempting To Try Out BCache On The Linux 4.1 Kernel
  3. CompuLab's Fitlet Is A Very Tiny, Fanless, Linux PC With AMD A10 Micro
  4. AMD A10-7870K Godavari: RadeonSI Gallium3D vs. Catalyst Linux Drivers
Most Viewed News This Week
  1. Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance
  2. Kubuntu 15.10 Could Be The End Of The Road
  3. NVIDIA Starts Supplying Open-Source Hardware Reference Headers
  4. KDBUS Won't Be Pushed Until The Linux 4.3 Kernel
  5. Linux 4.2 Kernel Gets Port To New Processor Architecture
  6. EXT4 Has Many Cleanups & Fixes For Linux 4.2
  7. The Staging Pull For Linux 4.2: "Big, Really Big"
  8. SteamOS "Brewmaster" Is Valve's New Debian 8.1 Based Version