Intel SGX for Linux: SDK, PSW, and Build Layout

The Linux SGX stack and its intended developers

Intel confidential-computing.sgx addresses a specific trust problem: protecting selected code and data from disclosure or modification by placing sensitive work inside an Intel SGX enclave. It is aimed at C++ application developers, systems integrators, and platform engineers working on Linux rather than users looking for a conventional application sandbox. An enclave is only one part of the security model. The repository describes the surrounding software as the SGX driver, SDK, and Platform Software, while separate projects provide related deployment and cryptographic components.

The repository is not a standalone enclave sample. It is the build and distribution home for a layered Linux stack. The SDK supplies enclave development interfaces, runtime libraries, and samples. Platform Software supplies host-side components needed to operate those enclaves. The README also points to Intel SGX DCAP for ECDSA remote attestation and to intel-sgx-ssl for cryptography based on OpenSSL. This separation matters when deciding what this repository can provide and what must be evaluated elsewhere.

The SDK now resides in the confidential-computing.sgx.sdk repository and is included here as an `sdk` submodule. The README says that this is a source-layout change rather than a packaging change: consolidated `make` targets still build all components, while released packages and installers remain unaffected. That arrangement keeps the top-level repository useful for coordinated Linux builds, but it also means repository users need to account for a submodule-based SDK layout.

Driver, hardware, and enclave execution boundaries

The Linux kernel has included the SGX driver since mainline release `5.11`, so the README states that a separate driver installation is unnecessary on modern kernels. The kernel exposes the device nodes `/dev/sgx_enclave` and `/dev/sgx_provision`. Those names are more useful than a generic claim of hardware acceleration because they identify the operating-system interfaces used when host software manages enclave creation and provisioning.

Driver availability does not remove the platform requirements. The processor and platform must support Intel SGX, and Flexible Launch Control must be configured. A machine may run a kernel that contains the driver while still lacking the required hardware capability or launch configuration.

The architecture separates trusted enclave execution from normal application execution. Sensitive code and data are selected for enclave protection, but the rest of an application can remain outside the enclave. The host environment remains responsible for ordinary inputs, outputs, lifecycle management, and any data transferred across the boundary. The repository's documentation points to the Developer Guide for enclave design patterns, sealing, and attestation concepts, while the Developer Reference covers `edger8r` and `trts/urts`. That division indicates a substantial development model rather than a simple compiler option.

The README does not claim that SGX protects an entire application automatically. Its wording is narrower: developers choose the code and data for which they seek disclosure or modification protection. Any adoption decision must therefore include enclave-boundary design, not just installation.

Building the SDK and Platform Software

The top-level `Makefile` makes the intended workflow explicit. Running `make` without a target prints tips and builds nothing. The documented SDK build target is `make sdk`, which the Makefile describes as proxied to the SDK submodule. Platform Software has a separate `make psw` path and requires additional tools documented in the README. The Makefile also mentions `make preparation` as a prerequisite for preparing source code before other targets.

A first source build can begin by checking the default guidance. This command only prints the repository's build tips, so no compilation output should be expected from it.

make

After the required README prerequisites are installed, the SDK target can build the Intel SGX SDK through the submodule arrangement.

make sdk

The Makefile distinguishes `make sdk` from variants such as `sdk_no_mitigation`, `sdk_install_pkg_no_mitigation`, and `sdk_install_pkg`. The Makefile excerpt does not provide the complete command-line requirements for each variant, so a team should not infer that these alternatives are interchangeable. In particular, selecting a mitigation-related target without understanding its build configuration could produce an installation different from the default SDK.

The documented PSW route is separate. Its Makefile guidance says to install additional prerequisites, obtain the latest Intel SGX SDK Installer, follow its Installation Guide, and then invoke `make psw`. That source-build sequence makes `make psw` a real operation, not a substitute for the SDK installation step.

Prebuilt packages and the first SGX application step

For users who do not need to build from source, the README directs Linux users to pre-built PSW and SDK packages at `https://download.01.org/intel-sgx/latest/linux-latest/`. It also points to the SDK installer on Intel's software download page. The README identifies a package-manager path as recommended. The actionable documented step is to use the linked package location and follow the associated Intel installation guide.

The first meaningful application activity is to build or install the SDK and then use its enclave samples. The repository says the SDK includes samples, but the README does not show a sample directory, source filename, compiler command, or run command. It therefore cannot support a verified first sample invocation here. The correct boundary is clear: obtain the SDK package, complete the platform prerequisites, and consult the SDK documentation for the specific sample and its launch procedure.

The documentation also identifies `/dev/sgx_enclave` and `/dev/sgx_provision` as the modern kernel device nodes. After installation, those nodes and Flexible Launch Control are concrete checks for whether the platform can participate in SGX operation. The README does not provide a single diagnostic command for verifying them, so it would be inappropriate to present an invented check as an official project procedure.

Attestation, aesmd, and supporting repositories

Intel SGX deployments often need more than enclave execution. The README identifies ECDSA attestation as an installation concern and points to the Intel SGX Data Center Attestation Primitives project for a Quoting Library, PCK Certificate Caching Service, Quote Verification Library, and related data-center tooling. It also links to `intel-device-plugins-for-kubernetes` for running SGX enclave containers in Kubernetes and for cluster attestation instructions. These projects solve different parts of deployment, so treating them as interchangeable would obscure the system's actual dependencies.

The README includes a section for managing the `aesmd` service. It does not provide the service-management command, so this article does not prescribe one. The named service is relevant to PSW installation because it is part of the documented operational surface. The project documentation should be consulted for the exact service behavior and configuration required by the selected release.

For cryptography, `intel-sgx-ssl` provides an SGX-oriented library based on OpenSSL, and the README notes an SDK build combination based on SGXSSL. That is a different dependency from the base SDK. A team whose threat model requires cryptographic operations inside an enclave should evaluate that project separately rather than assume the base stack supplies every cryptographic primitive or protocol.

Maintenance, licensing, and upgrade boundaries

The repository is not archived, and its last push was on 2026-08-13. The release history includes `sgx_2.30.1` on 2026-08-13, `sgx_2.30` on 2026-07-31, and `sgx_2.29` on 2026-04-30. These dates show that repository changes and versioned releases occurred during 2026. They do not establish compatibility for every SGX-capable machine, kernel, or attestation deployment.

The top-level file listing identifies `License.txt`, while the repository metadata labels the license as a custom license that GitHub cannot classify. The Makefile carries `SPDX-License-Identifier: BSD-3-Clause`, but that file-level identifier should not be treated as proof that every file uses one uniform license. Users who need distribution, linking, modification, or compliance decisions must inspect `License.txt` and the notices attached to individual components. This is a licensing boundary, not legal advice.

Upgrade cost is operational as well as source-level. Moving from legacy packages across releases is discussed in the README, and the SDK, PSW, DCAP, kernel driver, launch control, and attestation services must be considered as a versioned system. The README does not provide a universal upgrade procedure in the available text. A production adoption should use release-specific installation and attestation documentation rather than copying commands from an older SGX package set.

When Intel SGX is the wrong choice

Intel SGX is the wrong tool when the target CPU or platform does not support the required SGX features. A recent Linux kernel solves the driver-availability question only when it already contains the SGX driver; it does not create hardware support or configure Flexible Launch Control. It is also a poor fit for a requirement that can be met by ordinary Linux process permissions or container isolation, because the repository is organized around enclaves, sealing, attestation, and trusted execution.

The project introduces substantial platform assumptions. Developers need to decide which code and data cross the enclave boundary, understand untrusted host behavior, and account for attestation and quote verification when remote parties must assess the platform. The README's references to sealing, ECDSA attestation, DCAP, and the `aesmd` service show that an enclave binary is only one part of a larger design.

There is also a build-layout trade-off. Starting with release `2.30`, the SDK and enclave runtime libraries live in a separate repository and are vendored through the `sdk` submodule. The top-level Makefile preserves consolidated targets, but developers who need to modify SDK code must navigate that split or initialize the submodule according to their repository workflow. This is manageable, but it is not the simplest single-repository SDK layout.

Editorial conclusion

Adopt this repository when an application needs Intel SGX enclaves on Linux and the team can meet its hardware, kernel, SDK, and platform-service requirements. Do not choose it for machines without SGX support, or when an application only needs application-level cryptography or conventional process isolation. Verify processor support, Flexible Launch Control, kernel device nodes, the custom License.txt terms, and the exact build or package path for the intended release before adoption. For production enclave deployment, the decisive boundary is whether the selected SDK, PSW, DCAP components, and attestation service form a supported configuration on the target platform.

Frequently asked questions

Official sources

1. intel/confidential-computing.sgx on GitHub
2. Issues
3. Project website
4. README
5. Releases