Modifying existing applications to take advantage of confidential computing protections can present a significant hurdle, but there’s an open source project to help you get there.
In this episode of the Open at Intel podcast, we talk to Mona Vij, Principal Engineer at Intel Labs, leads Intel's efforts on Gramine, a library operating system that allows for running unmodified applications and, among other things, solves the problem of running applications out-of-the-box on Intel® Software Guard Extension (SGX)-enabled hardware. We'll dive into Gramine, a Project and discuss easing the path to running in a trusted execution environment.Confidential Computing Consortium project, and discuss easing the path to running in a trusted execution environment.
Katherine Druckman:
Gramine eases the path to running applications on Intel SGX- enabled hardware. Why is that interesting and who could benefit most from using it?
Mona Vij:
It’s for expert developers. You need to know about the Intel SGX feature, and even if you know what it provides, you still have to figure out what to do with it...Even though Intel SGX offers an SDK which abstracts away some of the nitty-gritty details, you still have to know how to use this SDK with your software. Gramine provides another layer of abstraction where it says, ‘hey, you can bring your application and we can give you automatic guarantees that Intel SGX provides, running your unmodified applications in an enclave.’
Katherine Druckman:
That sounds helpful, but what are the main challenges? If I'm a developer and I have my application, I've already written it, and I don’t want to make any modifications to use Intel SGX, what are the main challenges in integrating existing applications with trusted execution environments like Intel SGX?
Mona Vij:
As you mentioned, Intel SGX is software guard extensions, and it gives you a space to run your code where the confidentiality and integrity of your code and data is protected. Intel has a set of instructions to use this feature, but as a developer you have to know what you want to protect. Do you want to protect the whole application? Probably, but is there any sensitive data that your code is managing? A lot of times you have the code and data, which is millions of lines of code, and you must figure out what part of the code needs to be protected and what can be non-secure, but that can be challenging depending on how complex your software is. Typically, it's not one developer, it's a set of developers building an application.
In the early days we looked at Snort*, an intrusion detection system to make sure that no one, like an administrator or system software user who has root privileges can muck up your policies, for example. But Snort is such a large piece of code, and it has really hardened over the years. Now, if you need to change your code to run in an enclave, you might inadvertently introduce some bugs. That means you need to know this large body of code and you don't want to modify it if it has been battle tested over the years. A lot of developers want to be able to protect the whole workflow, everything that comes with the data as well as the code and that's what Gramine allows you to do.
Gramine takes away that burden from the developer. When you run your application on Gramine, it will automatically create the enclave for you and take your application and run it inside the enclave. When you want to execute a binary, you just type the executable name and it starts executing. With Gramine you can just type ‘gramine’ and the name of the binary and Gramine will do all the work of creating the enclave, loading your binary inside the enclave, and then you get those automatic protections.
Katherine Druckman:
Having Gramine be the thing that holds your hand through the security process in a way is very interesting.
Mona Vij:
That’s our ultimate goal for any arbitrary Linux* application but there are challenges on the Gramine side, too. It's great for certain classes of workloads, but other classes of workloads won't work out-of-the-box for multiple reasons. One is that Gramine is still work in progress, and the second one is there are certain classes of apps not suitable to run in a ring 3 enclave and those won't work.
Katherine Druckman:
How do secure enclaves found in modern processors help protect sensitive data and how does Gramine use the security features of Intel SGX to protect sensitive data in use?
Mona Vij:
Today we know that we can protect the data in store by using encryption when it sits on the hard disk. We can protect the data when it's being transferred. We can use encryption again over Transport Layer Security (TLS) or whatever, but when you're processing the data in the CPU, it's completely in the clear and if you’re a superuser or if you just have privileges on the system, you can dump the system memory and look at anything your program is doing. Of course, you need system root privileges, but with something like SGX, we want to take the system software, hypervisor, and everything else out of the trusted computing base. They still isolate your applications so one application can't look into the other application, but if I'm a superuser I can.
And how do I get that superuser out of the trust space? We bring the CPU to the trusted computing base. It's the CPU that offers everything, so when it's running in in this mode it's encrypted, meaning unless you are running inside that mode, you can access the code and the data, but if you're running outside the enclave, like if a root user tries to read your memory, they will basically get all ones, and if they try to write it, all the writes will be dropped, and it's done at the CPU level. Think of this as isolated protected memory that's only accessible in this enclave mode.
Katherine Druckman:
When adding this extra layer of complexity, how does using Gramine impact performance and what are some best practices to minimize that?
Mona Vij:
So, you know, nothing comes for free.
We have these extra access controls in the CPU, and when you're looking at certain memory, the CPU says, ‘no, you're not in enclave mode’ and it drops, and all of that adds cycles. Similarly, any time you leave the enclave, you can typically save your state when you switch address spaces and then restore when you resume. All of that state also needs to be encrypted, or we call it the ‘synthetic state’ for that enclave -- entry and exits from enclaves is very expensive.
If you're familiar with Linux applications, historically entry and exits from user space to kernel space were very expensive. It has gotten cheaper over the years, but still, every time you do ring transitions, there’s also more transition in the CPU. It's very expensive -- thousands of cycles. It's a lot more expensive than going from ring three to ring zero, going from enclave mode to non-enclave mode. But every time you make a system call, you must go to the kernel, and you have to leave the enclave.
The rule of thumb is that you don't want to leave the enclave too often. Try to avoid it. That’s the general rule of thumb for SGX. Gramine, on the other hand, is really nice. Before Gramine was adopted for SGX, it started out just as a LibOS, a compatibility layer, and the goal was to get performance enhancements. Gramine implements part of the kernel in a user space, that's why it's called a library OS. If an application makes a system call, the library OS processes it. You don't even have to go to ring ring zero. Instead of 300 or so system calls, it goes to ring zero after 40 or maybe 50 calls. That already reduces user kernel boundaries making it very attractive to port to SGX. In SGX we want to leave the enclave and have as few system calls as possible, and we can build this sort of protection layer. Any time you leave the enclave you need to be careful with the entries and exits and sanitize any inputs and outputs, so Gramine makes our life much easier. If you’ve got 300 or-so system calls and you have to do sanitization, the job is very difficult...
It started out as a research project called Graphene. The name changed when we joined the Confidential Computing Consortium.
Katherine Druckman:
Gramine joined the Confidential Computing Consortium in 2021. Can you tell us the basic principles of confidential computing?
Mona Vij:
Confidential computing is protection of data in use. Any time you're computing on sensitive data, if you're running in a confidential compute environment, it's protected. The Confidential Computing Consortium, which is part of The Linux Foundation*, has a definition for it, which is basically: protection of data and use by running it in a trusted execution environment. A trusted execution environment (TEE) is something that several of the hardware vendors offer, like Intel offers SGX and now Intel® Trust Domain Extensions (Intel® TDX).
Several other vendors also offer different trusted execution environments, practically all of them offer these confidentiality and integrity guarantees. One other thing all the trusted execution environments offer is this idea of attestation where are not only your confidentiality and integrity is protected, but you can prove to a remote party that you’re running in an enclave by presenting sort of a hash of your initial code. You can either prove my code was signed by so and so or this was the hash of my code. And then the hardware gives you the guarantee that it will not be tampered with, so attestation is a very powerful feature that TEEs offer.
For more of this conversation and others, subscribe to the Open at Intel podcast:
- Openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Or your favorite podcast player (RSS).
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.