Total Memory Encryption

[mkopec]

The problem you're addressing (if any)

Enable Total Memory Encryption on plaftforms that support it (e.g. TigerLake laptops)

Describe the solution you'd like

TME enabled by default where possible

Where is the value to a user, and who might that user be?

Better security in certain scenarios

Describe alternatives you've considered

n/a

Additional context

Certain enterprise laptops have this feature supported in the BIOS.

[macpijan]

We can add some references. Is it this one: https://www.intel.pl/content/www/pl/pl/architecture-and-technology/total-memory-encryption-security-paper.html ?

[miczyg1]

coreboot enables TME by default.

[Hypocrite1127]

coreboot enables TME by default.

What does it mean — should it work in Dasharo without a problem then? It doesn't seem to right now.

[miczyg1]

coreboot enables TME by default.

What does it mean — should it work in Dasharo without a problem then? It doesn't seem to right now.

It means that coreboot tells FSP to enable TME by default. It should work with Dasharo.

It doesn't seem to right now.

How can you tell?

[Hypocrite1127]

Right at the start of boot process, after selecting GRUB menu option, first message in the log IIRC:
x86/mktme: No known encryption algorithm is supported: 0x4
In my case it's on Arch Linux. So it seems like something tips the system off to even start considering TME, but it can't enable it properly for some reason. But I have no knowledge of inner workings of the process, unfortunately.

[zirblazer]

Also on Arch Linux (July Archiso LiveCD):

dmesg | grep tme

x86/tme: enabled by BIOS
x86/tme: Unknown policy is active: 0x2
x86/mktme: No known encryption algorithm is supported: 0x4
x86/mktme: enabled by BIOS
x86/mktme: 15 KeyIDs available

I have no idea how it is supposed to work.

[miczyg1]

It is just that Linux kernel is not yet prepared to support MKTME on ADL. This technology is too new and Linux does not keep up. For now on master branch Linux supports only AES XTS 128 encryption algorithm.

x86/tme: Unknown policy is active: 0x2
x86/mktme: No known encryption algorithm is supported: 0x4

The above values say that ADL MKTME uses AES XTS 256 which Linux does not yet know of. FSP enables MKTME correctly, but it is not firmware fault that OS does not know how to use it...

[pietrushnic]

Maybe our Embedded Systems Team could think about use of MKTME. @TomaszAIR this feature is definitely useful for Windows, so question is what are the plans and where are the patches for using MKTME in Linux?

[pietrushnic]

Quick googling give me this: https://lwn.net/Articles/787852/

[pietrushnic]

https://fossies.org/linux/xen/tools/qemu-xen/include/exec/confidential-guest-support.h

[miczyg1]

Quick googling give me this: https://lwn.net/Articles/787852/

Quick look at this gives me: Wed, 8 May 2019 17:43:20 +0300 which explains everything. Alderlake release date was 2021. Obviously, the code 2 years worth behind the technology will not support the newest microarchitecture.

[pietrushnic]

That's fine, but it is in interest of Intel to support that, so maybe there are some patches somewhere that support ADL.

[zirblazer]

MKTME was supposedly to be used for VM encryption:
https://www.linux-kvm.org/images/d/d7/Mktme_kvm_forum_2018.pdf

However, I have no idea whatsover about whenever enabling TME in Firmware means that there is even a single thing that you can use it with, or if the feature itself can be considered orphaned. The fact than the Linux Kernel isn't fully aware of it is not promising, maybe Xen or QEMU-KVM are. No idea about Windows.

Note than according to this: https://en.wikichip.org/wiki/x86/tme
TME itself may be transparent, but you still pay some sort of performance penalty. So is even questionable whenever you want for it to be enabled at all times.

[Hypocrite1127]

Wasn't TME supposed to provide just the protection of memory contents? It provides protection over attacks where you remove RAM from the PC and freeze it to retrieve encryption keys contained inside. With TME, it's not possible, as (IIRC) encryption key to the TME are stored in CPU cache.

[pietrushnic]

I beleive we should look at this and think how open version could look like.

[pietrushnic]

@miczyg1 @mkopec aren't we enabling TME by default in our builds? If not then why? If yes, why this ticket is open? We should also have tests associated with testing this feature, which should be quite trivial according to matrix discussion:

dmesg | grep tme

[mkopec]

@pietrushnic I believe we are, but it's not actually supported on certain SKUs: #464

[miczyg1]

@pietrushnic I was expecting the issue to be closed after this comment: #175 (comment)

but it is up to the issue creator to do this if he is satisfied with the results/answer

[pietrushnic]

@mkopec I guess if coreboot enables TME by default, then the only thing we can do is expose proof it really does, but that should happen through dmesg|grep -i tme, so this issue seems to be noop. I guess most people ask if their CPU support TME not if Dasharo/coreboot enables TME. OTOH, it looks like for end users enabling TME is a value even if it is noop on coreboot side, so maybe we should clearly state that in the "feature matrix"?

@macpijan WDYT?