Lenovo ThinkPad T14 AMD + Linux + full disk encryption

Hello everyone,

I have embarked myself on a new adventure with my relatively new Lenovo T14 laptop. I bought a 1TB Samsung 970 Pro with the idea of doing a full disk encryption and loosing as lowest performance as possible. I am currently on Windows 10 Workstation with bitlocker enabled (the BIOS has an option to enable disk encryption, which adds extra security features like biometric and password authentication). I’m planning on switching to some Linux distribution (possibly Gentoo), but I’m worried that I will loose some of those functionalities and also some disk performance.

Has anyone here have experience with disk encryption and the newer ThinkPad laptops?

1 Like

Just don’t encrypt the files your system needs to boot. You’ll have a bad time recovering from that mistake… So, “full” disk encryption is a bad idea.

Instead of Gentoo (good as it is) try Funtoo. That’s essentially Funtoo-on-the-edge with newer software and thus, better support for new-ish hardware. And they have an excellent install guide that even I can follow :wink:

Thanks for the advice @Dutch_Master. I have experience with Gentoo, it’s been my distro of choice for my personal workstation for the past 15 years, so I’m pretty familiar with the install. I have tried Funtoo a couple of times and it is pretty good too.

What kind of problems are you referring to?

1 Like

Simply said, the kernel has no way to decrypt the data it needs to boot, as that data is on the encrypted file system. I was triggered by your thread as I’d read this one: click on the Devuan forum.

Well, there is a way of decrypting the boot partition using some GRUB functionality. I did it in the past, it wasn’t all that easy, but I was able to achieve the full encryption.

Ah, I see. I wasn’t aware of that. So, best of luck then :wink:

Most people just leave /boot or /boot/efi decrypted, but encrypt / and /home.

If you want to do fun stuff with yubikey for decryption, you must leave boot decrypted.

1 Like

Yep. Troubleshooting LUKS and GRUB is no fun. cryptsetup in initramfs is way easier, and the only things it exposes are kernel and initramfs stuff.

1 Like

Unfortunately, if security is what you’re after, malicious kernel modification is not what you want.

… or grub modification.

https://wiki.ubuntu.com/UEFI/SecureBoot
https://wiki.debian.org/SecureBoot

Is where that stuff is described.

1 Like

At the end of the day, there’s no such thing as complete security.

3 Likes

The T14 has discrete TPM which could be leveraged. Alternatively you could clear the PEK and use secureboot with custom keys

A lot of work, but possible to secure.

Alternatively the 970 has OPAL 2.0 self-encrypting support, which you may be able to lock/unlock before boot in firmware.

1 Like

That’s what I want to understand. As I am on Windows 10 right now, I guess the OPAL 2.0 is being managed by BitLocker itself, right? or is it actually controlled by the disk itself?

So, as far as I was able to understand, if the TPM chip is enabled on the BIOS I will have hardware level encryption for the nvme disk. I could also user dm-crypt the encrypt the disk on a software level as well, to have an extra level of security.

Will any of these setups have any impact on the disk I/O’s performance?

If I encrypt the 970 Pro with dm-crypt, will I be using it’s built in OPAL 2.0 hardware encryption?

The encryption is all done on-disk for OPAL. There is a shadow MBR that may contain an authentication app, as well a multiple zones w/different keys.

So, as far as I was able to understand, if the TPM chip is enabled on the BIOS I will have hardware level encryption for the nvme disk.

A TPM can act as a hardware password (it can also monitor the boot process, and only unlock secrets if it proceeds as expected.)

But a TPM is not a requirement of OPAL itself.

Bitlocker is actually pretty versitile, it can use a text password on opal, or software encryption on top of secureboot. It’s not neccessarily doing the same thing in all cases.

I could also user dm-crypt the encrypt the disk on a software level as well, to have an extra level of security.

The thing about OPAL is, once the drive is unlocked, it’s unlocked until power is removed. If an attacker can pull the drive without killing power, or chainboot into another OS, they get the data in the plain.

Also you have to trust the hardware vendor to get it right the first time (honesly who ever wants to update the firmware of a disk with live data). Also many self-encrypting drives are out there with some level of vulnerability due to improper implementations.

And with dm-crypt it is possible to steal keys via a kernel exploit. This dual layer may prevent some attacks, but not really needed for basic data protection and compliance.

It’s also possible to link your dm-crypt setup to the TPM.

Will any of these setups have any impact on the disk I/O’s performance?

If I encrypt the 970 Pro with dm-crypt, will I be using it’s built in OPAL 2.0 hardware encryption?

OPAL 2 has no impact on disk performance, as I am lead to believe these drives are always encrypting anyways as a good mix of bits in the cells helps improve performance. Additionally it makes secure-erase compliance trivial and quick.

However dm-crypt does not leverage OPAL at all. The disk controller never sees data in the clear. The nice thing is you don’t have to trust the hardware vendor to get it right and the defualt config works the same was on every system

DM-crypt with AES on modern x86_64 hase very little practical performance impact. The processors have acceleration so there’s not a bottleneck outside high-end workstations, though battery life may be slightly worse if you are hitting the disk a lot.

But not everyone likes AES, and the software option does give you more flexibility.

Personally I’d use on dm-crypt for laptops, and for extra security or convenience to lean on a well tested hardware token rather than on the drive.

This is a common talking point, but is it really true? It seems like it’s only true in that it doesn’t impact CPU overhead much, without saying anything about data throughput and access latency. In my own testing, software encryption really drags performance on smaller data transfers (4K), but not larger ones (1Mb).

Here’s a similar chart from Intel showing difference in the smaller, like 4k, transfer speeds:

<From https://youtu.be/5mmJlNplcAY?t=580 >

Mostly

Looks like write performance Q32 actually improved with encryption. (filesystem and block layers can be weird sometimes)

The worst hit being RND4k at Q32T16, which is a disaster if you’re pushing a database in production.

But from what I understand on the desktop you’re usually in the Q1 or sequential access patterns… and the 10-20% hit there I’d call barely noticeable.

Of course hardware behavior and usage varies so it may not be good for you. But I don’t find dm-crypt to be getting in my way.