10

What would be the Read-/Write-overhead when using dm-crypt (LUKS) as full disk-encryption (including root partition) on a Linux-Desktop (Ubuntu)? I plan to stack it like so: LUKS > LVM > ext4 The CPU in use on the system would be a Core2 Duo 2.1 GHz with 4GB of RAM.

  • Would encryption of such a system create a great/noticeable overhead?
  • Are there any recent benchmarks to be found on the net? What is your personal experience?
  • Are there any settings I can make to improve performance?

Thx for your help.

Improve this question
12

There is no I/O-overhead involved in dm-crypt - just CPU overhead ... ;)

On a Athlon 64 2.6 GHz dual core system for example I can copy from one dm-crypt disk to another with ~ 40 MB/sec (2.6.26 Kernel, Seagate 1.5 TB SATA disks).

For performance make sure that the for your architecture optimized aes module is loaded, e.g.

$ lsmod | grep aes
aes_x86_64             12416  6 
aes_generic            32552  1 aes_x86_64

Regarding data-safety, there is no need to disable the write-cache because of dm-crypt. Old versions didn't support write-barriers, but since 2010 (kernel 2.6.31 or so) dm-crypt does support them (respectively force-unit-access - FUA).

Btw, one can argue that it does not really makes sense to encrypt the root-partition.

However, encrypting swap does make sense.

Improve this answer
  • 1
    One might argue as well that messing around with hdparm when you don't know what you're doing (or only think you know) can damage your hard drives. – amphetamachine Feb 24 '12 at 23:30
  • Encrypting the root partition makes sense if your threat model includes the possibility of an adversary gaining temporary physical access and booting in single user mode or from a USB drive and installing malware such as a key-logger or rootkit. For regular users, it also means not having to worry about forgetting to encrypt /tmp (if it's not mounted with `tmpfs) and any other directories that might leak private data. – Anthony Geoghegan Oct 11 '16 at 10:30
  • 1
    @AnthonyGeoghegan, this is perhaps effective against some adversaries. But to protect against the threat model you describe you also have to secure the bootloader (e.g. with a firmware that cryptographically checks the bootloader before executing it). – maxschlepzig Oct 11 '16 at 19:01
  • @maxschlepzig That very thought occured to me as I wrote the comment earlier but I didn't want to go overboard with disclaimers and provisos in a small comment box. The second reason is probably more important: I use FDE (on my 10 year old laptop) so I don't have to worry (as much) about credentials and private keys in /etc or some other sensitive data somehow being logged to /var/ (upvoted, BTW). – Anthony Geoghegan Oct 11 '16 at 21:05
0

Ext4 may be a bad choice of filesystem if you are planning on performing LVM snapshots. I would advise doing substantial disk performance checking before going live, experiementing with block sizes on both FS and LVM. My experience was with Ext3, but the other articles I saw at the time implied that Ext4 had simular problems.

I solved it by using XFS as the filesystem.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.