Gramine gives a Linux binary an SGX enclave without rewriting it
A library OS for Linux multi-process applications, with Intel SGX support
At a glance
- What is it?
- Gramine is a library OS that loads an unmodified Linux application into an Intel SGX enclave, so a program can be shielded from a hostile host without the porting effort a full virtual machine would demand. It was renamed from Graphene because that name was too common to trademark, and its public documentation is its main interface, since the repository itself is mostly a C library.
- Who is it for?
- Adopt Gramine if you need to run an existing Linux binary inside an SGX enclave and cannot rewrite it, since the whole design goal is that native unmodified binaries work with minimal host requirements. Skip it if your threat model is a merely curious co-tenant, because the protection is aimed at a malicious system stack rather than at isolation from other workloads, and if you cannot accept enclave memory limits, since the enclave size is a hard constraint on the workload.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A library OS loads one binary rather than booting a system
Gramine is a lightweight library OS designed to run a single application with minimal host requirements. The framing is deliberate: a library operating system is not booted, it is loaded, and the application it hosts runs as the only meaningful workload inside it.
The stated benefit is comparable to running a complete OS in a virtual machine, and the specific benefits listed are guest customization, ease of porting to different OSes, and process migration. The point of a library OS is that you get the isolation property of a VM without the cost of a VM, which in practice means the application does not know it is being confined and does not need to be modified for it.
Gramine supports native, unmodified Linux binaries on any platform. Currently, Gramine runs on Linux and on Intel SGX enclaves on Linux platforms, so the enclave path is the one that is specific to a platform while the library OS model is general.
The project was formerly named Graphene, and the documentation explains why it was renamed. The name Graphene was deemed too common, could be impossible to trademark, and collided with several other software projects, so Gramine was chosen.
The code is C, with the LGPL-3.0 licence, and the last push was on 2026-10-22. The project describes itself as a growing project with a growing contributor and maintainer community, with the code and overall direction determined by a diverse group from universities, small and large companies, and individuals.
The lift and shift path into confidential computing
The deployment story Gramine pushes is the lift and shift paradigm for bringing unmodified applications into Confidential Computing with Intel SGX.
The motivation is stated plainly: in untrusted cloud and edge deployments, there is a strong desire to shield the whole application from the rest of the infrastructure. Gramine is positioned as protecting applications from a malicious system stack with minimal porting effort.
That phrase, a malicious system stack, is the precise threat model and it is worth being literal about it. The adversary here is the hypervisor, the kernel, the firmware and the BIOS, not another application. What the enclave boundary buys you is that the host cannot read the protected memory, and cannot lie about what happened inside it. What it does not buy you is anything about other tenants or other processes on the same machine, and it does not remove the need for the application to be correct.
The practical consequence is that an existing Linux service can be moved into an enclave without being rewritten, which is the difference between confidential computing being a research topic and being a deployment plan. For an organisation with a working service and a compliance requirement, that is the whole value proposition.
The cost of the model is the same in every direction: you are constraining a program to a fixed, small, unforgeable memory region, and everything the program needs from the host now goes through a carefully specified interface.
The manifest is where the application is actually described
Gramine is configured by a manifest file, and the documentation has a dedicated page on the manifest file syntax, which tells you how central the concept is.
The manifest is the enumeration of what the application is allowed to do: which files it may open, which sockets it may use, which environment variables it sees, and which other processes it may talk to. In an enclave, the default answer to any question about access is no, and the manifest is the place where you say yes.
This is the practical difference between running a program in a VM and running it in a library OS. A VM has a filesystem and a network stack that the guest owns; a library OS has a manifest, and the list of allowed resources is written down rather than implied by the host configuration. That makes the security boundary auditable in a way a VM's configuration often is not.
It also makes it work. The library OS approach exists precisely so the unmodified binary can run, and the manifest is the part of the design that replaces the operating system conventions the binary expects. When a program does something the manifest does not permit, the failure is at the manifest rather than deep inside the application.
The repository tree shows the structure that supports this. There is a common/ directory, a pal/ directory, which is the platform adaptation layer where the differences between running natively and running in an enclave are handled, a libos/ directory for the library OS itself, and a keys/ directory for the key material that attestation depends on.
Attestation is the feature that makes an enclave worth having
Enclave protection without attestation is mostly theatre, because the client has no way to know what code it is talking to. Gramine documents remote attestation as a separate topic with its own page, and the repository carries a keys/ directory at the top level.
The workflow the documentation points to is the standard one. The application signs or measures itself, the measurement is quoted to a remote party, that party verifies the measurement against what it expects, and only then does the client release the data it was protecting. The measurement is the identity of the code, and the keys directory holds the material for producing and verifying it.
A dedicated page on performance tuning and analysis of SGX applications in Gramine suggests that the project expects people to run this in anger rather than only in demonstrations. Enclave execution is not free, and the interaction between paging, the host operating system and the workload shows up in latency numbers.
There is also a maintained list of companies experimenting with Gramine for their confidential computing solutions, which is the closest thing in the documentation to a deployments page. The list is maintained by the project itself, and its existence is a useful signal about the level of real-world attention, though it is a list of experiments rather than a list of production systems.
What lives in the repository, and what lives in the documentation
This is a project where the repository and the documentation are two different things, and knowing which is which saves time.
The repository is a C codebase built with Meson, with meson.build and meson_options.txt at the root, a clang-format configuration, a pylintrc for the Python components, and pytest.ini for the test suite. There are subprojects/ for vendored dependencies, a scripts/ directory, a tools/ directory, and CI-Examples/ for the example applications used in continuous integration. Packaging is present in several forms: a debian/ directory, a gramine.spec for RPM builds, and a packaging/ directory, alongside a CHARTER.rst, a DCO and a CODE_OF_CONDUCT.rst.
The documentation is hosted on Read the Docs, and the README links to the pages that matter: installation options, running a sample application, complete building instructions, manifest file syntax, performance tuning and analysis for SGX applications, and remote attestation. The README also carries a Read the Docs badge and an OpenSSF Best Practices badge.
The license arrangement is worth noting. The project is LGPL-3.0, and there is a LICENSE.txt alongside a LICENSE.addendum.txt, which is the pattern used when a project adds terms beyond the base licence text, most often for components that cannot carry the LGPL. If you are considering a link-time or distribution model, that addendum is the document to read.
On releases, the tags are v1.9 from 2025-06-20, v1.8 from 2024-10-21 and v1.7 from 2024-04-24, while the last push is on 2026-10-22. So the source is being worked on more recently than the release tags suggest, and the tags are the conservative number to plan against.
Where Gramine sits against a full virtual machine
The honest comparison is with running the workload in a VM under a confidential-computing hypervisor, and against writing a bespoke SGX application with the Intel SDK.
Against a VM, Gramine is far lighter and gives a much smaller trusted computing base, because there is no guest kernel and no guest operating system to trust. What you give up is the general-purpose environment. A VM can run anything, Gramine can only run a Linux application whose behaviour you have described in a manifest, and the manifest has to be kept in step with the application as it changes. The lift and shift promise holds for a stable service, and gets harder every time the binary starts making new kinds of system call.
Against the Intel SGX SDK, Gramine removes the rewrite. A bespoke SGX application gets a smaller trusted base and finer control, and costs you a port to a new programming model. Gramine keeps your code as it is and accepts the cost of a manifest, extra runtime layers and a smaller set of usable primitives.
What Gramine is not is a tool for running untrusted code safely on a shared machine. Its purpose is protecting your code from the host, which is the opposite direction. Anyone reaching for it as a container replacement will find the model is unfamiliar and the manifest will be the hard part.
The support model is community based: GitHub Discussions for questions, Gitter for chat, GitHub issues for bug reports and feature requests, an email list at [email protected] with a public archive, and a separate [email protected] address for reporting vulnerabilities alongside the repository's security policy.
Editorial conclusion
Adopt Gramine if you need to run an existing Linux binary inside an SGX enclave and cannot rewrite it, since the whole design goal is that native unmodified binaries work with minimal host requirements. Skip it if your threat model is a merely curious co-tenant, because the protection is aimed at a malicious system stack rather than at isolation from other workloads, and if you cannot accept enclave memory limits, since the enclave size is a hard constraint on the workload. Verify first that your CPU and platform support SGX, that the application fits in enclave memory, and that the manifest you write reflects the exact syscalls the binary makes, because the manifest is where the trust boundary is actually configured.
Frequently asked questions
What is Gramine and how is it different from a virtual machine?
Gramine is a lightweight library OS designed to run a single application with minimal host requirements, loading it rather than booting it. The benefits are comparable to running a complete OS in a virtual machine, including guest customization, ease of porting to different OSes and process migration, without the cost of a guest operating system.
Does Gramine need my application to be modified?
No. Gramine supports native, unmodified Linux binaries on any platform, and the lift and shift paradigm is about bringing unmodified applications into Confidential Computing with Intel SGX with minimal porting effort. What you do have to write is the manifest that describes what the application is allowed to do.
What threat does Gramine protect against?
The stated goal is protecting applications from a malicious system stack, and the use case is shielding a whole application from the rest of the infrastructure in untrusted cloud and edge deployments. Gramine runs on Linux and on Intel SGX enclaves on Linux platforms, and remote attestation is what lets a remote party verify the code it is talking to.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/gramineproject-gramine)Was this useful?