The 2019 Laptop Performance Cost To Linux Full-Disk Encryption

[reavertm]

What about using OPAL?
What drawbacks does it have?

You mean "hardware" encryption that is supported by most SSDs and NVMEs, unlocked via UEFI directly as so called "HDD password", invisible to operating system, often embedding some uuid in salt when initial key is written or making it part of the hash (HP business laptops), once unencrypted making disk often transferrable (even if you know the password) only between the same models?

[shmerl]

shmerl ah yes, we also tried to encrypt /boot, but stopped short of it, due to the installer spitting errors --or was it GRUB after the fact? -- and a lack of time (IIRC).
I did so on my Arch system, leaving only the secureboot-signed kernel image in the EFI partition. At this point, my biggest concern lies with the initramfs. Any tips on signing that one?

EFI partition commonly only needs grub, why do you put the kernel there? The kernel can sit on your normal encrypted root partition, under /boot. Though I'm not using signing, may be that has different requirements.

[Guest]

Roughly what I expected based on practical experience with using encrypted disks on laptops (Windows and Linux). There's a few different variables that affect practical throughput performance. One of the biggest is which drive interface you're using. It's been my experience that, in general, SATA drives suffer considerably less performance impact because the maximum throughput on those buses is usually less than the actual processing performance of the CPU's hardware encrypt/decrypt support. Spinning rust is generally even less impacted than SSD. Again, because the CPU can run the instructions faster than the drive can transfer data. The bottleneck there becomes the number of threads the CPU can handle with the acceleration. I'm not sure about the most current Intel CPUS, but traditionally they could only handle one encryption thread at a time while the Ryzens can handle 2 at once.

This changes with NVME drives because they can handle greater throughput and apparently it's a higher throughput than what the CPU can process. The CPU is once again the bottleneck that it generally wasn't with SATA only systems, so you see a slowdown on a system that's using NVMe drives even with hardware based de/encryption support.

Ah I see. Yeah, I'm using SATA drives on my desktop, and their max read/write speed is 480 MB/sec, while the CPU's AES encryption/decryption is around 2000 MB/sec. So in my case I don't face any bottlenecks.

Need to check my laptop though.

[Slithery]

What about using OPAL?
What drawbacks does it have?

It's impossible to audit the security code that you're depending on.
Depending on the implementation it can be trivial to unencrypt data without the key.

In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations,

In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret.

https://bit-tech.net/news/tech/stora...erabilities/1/
https://www.ru.nl/publish/pages/9092...ft-paper_1.pdf

[leetNightshade]

This benchmark leaves me wondering, well how does it compare to ZFS Encryption?

[stevea]

Modest but very real performance impact. I am left thinking that I want /home & swap & and a few bits in /etc and /var encrypted, but not much else.

[Slithery]

Modest but very real performance impact. I am left thinking that I want /home & swap & and a few bits in /etc and /var encrypted, but not much else.

Which would only be of any use if you could guarantee that no-one else had physical access to your machine. Otherwise they could drop a modified binary in your system path to do anything they wanted.

[zxy_thf]

Hm, those results seem a bit weird. If using AES XTS, and with AESNI being present and enabled, there shouldn't be much of a performance impact IMO.

I'm guessing a fraction of performance impact comes from the dirty state of the SSD. i.e. not being trimmed before reinstalling with LUKS.

[_Alex_]

I'm trying to make sense of this. In an old quad core (10yr-old) I could visibly see my CPU maxing out when copying from one encrypted drive to the other. My mb/sec were CPU-limited. Now, with current CPUs, if CPU load doesn't go up significantly (to make CPU the bottleneck), then why is performance degraded? FS-related inefficiencies?

[cybertraveler]

Which would only be of any use if you could guarantee that no-one else had physical access to your machine. Otherwise they could drop a modified binary in your system path to do anything they wanted.

It would protect them from a one off theft of their computer by a typical thief. e.g. if their house was robbed or laptop swiped.

If someone is targeting you specifically to steal data or deply malicious code on your systems and they can get physical access to the systems, pretty much all bets are off (unless you have one of those fancy ORWL computers, for instance).