Intel MKTME Support Being Prepped For The Linux Kernel: Total Memory Encryption

[phoronix]

Phoronix: Intel MKTME Support Being Prepped For The Linux Kernel: Total Memory Encryption

Intel developers are working on bringing transparent memory encryption support to the Linux kernel that works in conjunction with upcoming Intel platforms...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-MKTME-Linux-Patches

[xxmitsu]

Does this relates to Intel SGX? https://www.neowin.net/news/spectre-...d-by-intel-sgx

[Maxim Levitsky]

Does this relates to Intel SGX? https://www.neowin.net/news/spectre-...d-by-intel-sgx

Thankfully no. This feature is fully user controllable, with keys loaded by the user. Its only protection is against rogue hardware trying to DMA the system's memory, and from cases when one guest (ab)uses some hardware that passthrough'ed to it to make it read (using DMA) memory of other guest or the host.

[starshipeleven]

Thankfully no. This feature is fully user controllable******, with keys loaded by the user. Its only protection is against rogue hardware trying to DMA the system's memory, and from cases when one guest (ab)uses some hardware that passthrough'ed to it to make it read (using DMA) memory of other guest or the host.

****** this does not guarantee that also malware or other stuff that pwns the UEFI or ME cannot bypass it.

[ssokolow]

****** this does not guarantee that also malware or other stuff that pwns the UEFI or ME cannot bypass it.

Sure, assuming they can either tamper with the boot process to monkey-patch the programs or intercept the cleartext or key. It's entirely possible that the system is implemented in such a way that their Ring -3 DMA can only see the encrypted data. Has Intel published anything on this sort of interaction?

[rianquinn]

Anybody know when this comes out? Could not find information about which upcoming CPUs will have this feature.

[linuxgeex]

This is an interesting feature for sure. Obviously the kernel space needs to be able to write data to a DMA memory region with the correct key such that the DMA can scan the memory out to the device. Implications are that the kernel needs to be able to operate on memory with multiple keys at the same time, and goodbye zero-copy scatter-gather DMA for high-end networking. On the bright side this could be used to mitigate Spectre, assuming that the memory stays encrypted in caches, and that a secure_fork() is implemented that creates a new process with a new memory key.

[starshipeleven]

Sure, assuming they can either tamper with the boot process to monkey-patch the programs or intercept the cleartext or key.

Wut? They just need to exploit ME interfaces or the UEFI interfaces to either get a code execution or access to flash.

It's entirely possible that the system is implemented in such a way that their Ring -3 DMA can only see the encrypted data. Has Intel published anything on this sort of interaction?

I tend to go with the "path of least resistance" on this one.

It's much easier to have this thing run by a programmable processor they are already embedding in the system (the ME) instead of designing new hardware to do it independently.

[ssokolow]

Wut? They just need to exploit ME interfaces or the UEFI interfaces to either get a code execution or access to flash.

I tend to go with the "path of least resistance" on this one.

It's much easier to have this thing run by a programmable processor they are already embedding in the system (the ME) instead of designing new hardware to do it independently.

I'm not sure what you mean by "access to flash" (Doesn't Boot Guard use a public key in ROM to verify the UEFI which then uses Secure Boot to verify the OS? Wouldn't that make access to flash unhelpful?) but "get a code execution" is what I meant by the overly specific "tamper with the boot process to monkey-patch the programs".

I was thinking about how the article said that the minimum number of encryption domains that could be provided by a system supporting MKTME was 3. (Which I'm imagining would be one for the ME to use to enable storing DRM secrets in RAM, one for exchanging encrypted data between the OS and the ME, and one domain the ME potentially wouldn't know the decryption key for, depending on what its Ring -3 DMA can see.)

[starshipeleven]

I'm not sure what you mean by "access to flash" (Doesn't Boot Guard use a public key in ROM to verify the UEFI which then uses Secure Boot to verify the OS? Wouldn't that make access to flash unhelpful?)

Are you assuming Boot Guard is actually set up properly by the OEMs? Because it's not, and this allows to bypass it.

https://www.uhwo.hawaii.edu/cyber/intel-boot-guard-bypass/

Really, all it takes to make the goddamn system safe from digital attack without having to rely on OEMs doing a good job on software is a hardware switch that forces the SPI flash chip into read/only mode, easy, simple and freedom-respecting.

but "get a code execution" is what I meant by the overly specific "tamper with the boot process to monkey-patch the programs".

According to the latest research, you can pwn the ME regardless of boot process. https://www.theregister.co.uk/2017/1...ffer_overflow/