About performance and root partition encryption

[imlibra]

I hope it can encrypt the system root partition, and the performance is low because it need a copy to user-space's daemon in order to communicate with the enclave.

Is it possible to do the communication task inside kernel-space for performance improvements and root partition encryption?

[ayeks]

Hey,

thanks for your interest in the project! The performance is so low because of the Netlink interface that is used to transfer data blockwise between user space and kernel space. We had the same idea like you in the beginning: Make it possible to harden kernel components in kernel space by moving them into SGX enclaves. However the problem is that enclaves can only be entered in user space - but must be created in kernel space. I briefly discussed that in the Background section of the readme.

If you want more information on my work and the design decisions I made, have a look at my thesis: http://ayeks.de/assets/blog/2016-12-15-tresorsgx/tresorsgx.pdf The answer to your question can be found in 2.1.5 Enclave Lifecycle .

Detailed information regarding the performance can be found here. I believe the usage of SYS V Message Queues or SYS V Shared Memory will improve the performance.

Which additional questions do you have on your mind?

[imlibra]

Hi,

Is it possible to do all of enclave operations and managements task like AESM daemon etc inside kernel? Not only because it will significant improve the performance, but can unlock the disk in pre-boot environment and make root partition encryption possible.

[ayeks]

As I said, it is not possible to enter the enclave from ring 0 (kernel space). The CPU must be in ring 3 (user space) to be able to make the call to enter the enclave. Have a look at the description for entering an enclave in the official Intel documentation for SGX.

I don't really know why Intel decided to make it impossible to enter enclaves in kernel space. If you want to speculate about their reasons feel free to do so. My only idea is that it is not the desired use-case for SGX to be executed in kernel space.