search

Dasharo / dasharo-issues

The Dasharo issue tracker
https://dasharo.com/
24 stars 0 forks source link

Total Memory Encryption #175

Open mkopec opened 2 years ago

mkopec commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

coreboot enables TME by default.

Hypocrite1127 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

pietrushnic commented 2 years ago

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

miczyg1 commented 2 years ago

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 commented 2 years ago

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

zirblazer commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

pietrushnic commented 1 year ago

@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 commented 1 year ago

@pietrushnic I believe we are, but it's not actually supported on certain SKUs: https://github.com/Dasharo/dasharo-issues/issues/464

miczyg1 commented 1 year ago

@pietrushnic I was expecting the issue to be closed after this comment: https://github.com/Dasharo/dasharo-issues/issues/175#issuecomment-1221517258

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

pietrushnic commented 1 year ago

@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?