How large is the TCB of SGX-LKL? about sgx-lkl HOT 6 CLOSED

Hi,

I would not say that it is “the entire Linux kernel”. Large parts of the Linux kernel are device drivers and functionality that directly interacts with the hardware. This is not meaningful or required for SGX enclaves, and we create an Linux kernel version that only includes the bare minimum of functionality that is needed to implement the POSIX system call interface inside the enclave.

Since Linux binaries require a compliant implementation of the POSIX interface to execute, one cannot avoid providing that implementation as part of the TCB inside the enclave.

from sgx-lkl.

I understand that SGX-LKL does not need to include the part of Linux kernel that interacts with hardware directly. But it is still a bit of vague to me as to how much is "the bare minimum" of Linux. Could you give the total number of the lines of code of LKL that is included in the enclave? Or, you can just give me a list of directories so that I can do the math myself.

Thanks a lot.

from sgx-lkl.

Hmm, it's not that easy. You could look at an SGX-LKL build and consider all source files whose object files are linked into libsgxlkl.so.

The problem with this is that we haven't optimised the kernel configuration yet, and currently we are including functions that aren't necessary (e.g. parts of the USB stack, unnecessary file systems etc). We should update the kernel configuration to remove these before building SGX-LKL.

More fundamentally, counting source code lines is a crude way of measuring the TCB size to judge security. For example, the Linux kernel code has a maturity that other experimental library OSs have not. In that sense, having more Linux kernel code in the enclave may be more secure than having fewer lines of code but with security vulnerabilities :-)

from sgx-lkl.

Given the complexity of Linux's build system, I don't think counting all the source files is a trivial task. So, looking for a quick answer, I built the sgx-lkl according to the README and found that libsgxlkl.so is as large as 65MB. I didn't use DEBUG=1 so I don't think there are debug symbols in the resulting libsgxlkl.so. In my experience, a binary of size of this magnitude means millions of lines of C code.

This is a good project. I am not judging anything; I am just looking for some answers. Thanks for you kind explanations.

from sgx-lkl.

Hi @tatetian,

I think even when building without DEBUG=true the file does not get stripped and will contain some debug information. If you look at the output of size you'll get a better idea of the size of loadable segments that will actually end up inside the enclave. For me, it shows a size of 7.25MB.

I have previously tried to get an estimate of the lines of code of the Linux kernel that get included. It's indeed not very straightforward. If you simply look at the lines of code of all *.o files generated, the result is around ~420k lines of code. However, this will ignore conditional code blocks controlled via preprocessor defines as well as header files. So this is a very rough estimate.

As @prp already mentioned, there is definitely a lot of potential for optimisation. We haven't really looked into optimizing the kernel configuration to get rid of unused features. Same for third party dependencies.

In any case, there are always trade offs. In the case of SGX-LKL the TCB definitely has a significant size. The benefit of this approach is the minimal reliance on the host system even for complex applications. The alternative would be to increase the reliance on the host by doing more work outside of the enclave. For example, you could rely on the host file system rather than having a file system inside the enclave. Obviously you now expose a lot more information to the host and you'll have to find a way to sufficiently protect the integrity and confidentiality of that data.

from sgx-lkl.

Hi @cpriebe ,

I agree that different SGX LibOSes have different trade-offs. It is exactly for this reason that I raised this question, trying to figure out the TCB of SGX-LKL. Eventually, it is up to the end users to decide which tradeoffs are most suitable for them.

Thanks @prp and @cpriebe for your inputs. This clarifies the TCB issue for me and other people who are interested in the project.

from sgx-lkl.