Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ssokolow
    replied
    Originally posted by starshipeleven View Post
    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/in...-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.

    According to the latest research, you can pwn the ME regardless of boot process. https://www.theregister.co.uk/2017/1...ffer_overflow/
    *sigh* There's me giving OEMs too much credit again.

    Damn shame SPI doesn't specify some kind of Write Enable line that an aftermarket switch could be patched into like with the battery-backed RAM in various video game cartridges.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ssokolow View Post
    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/in...-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/

    Leave a comment:


  • ssokolow
    replied
    Originally posted by starshipeleven View Post
    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.)

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ssokolow View Post
    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.

    Leave a comment:


  • linuxgeex
    replied
    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.
    Last edited by linuxgeex; 07 March 2018, 04:32 PM.

    Leave a comment:


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

    Leave a comment:


  • ssokolow
    replied
    Originally posted by starshipeleven View Post
    ****** 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?

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Maxim Levitsky View Post
    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.

    Leave a comment:


  • Maxim Levitsky
    replied
    Originally posted by xxmitsu View Post
    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.
    Last edited by Maxim Levitsky; 05 March 2018, 02:50 PM.

    Leave a comment:


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

    Leave a comment:

Working...
X