Hubbry Logo
Software Guard ExtensionsSoftware Guard ExtensionsMain
Open search
Software Guard Extensions
Community hub
Software Guard Extensions
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Software Guard Extensions
Software Guard Extensions
Software Guard Extensions
View on Wikipedia
from Wikipedia

Intel Software Guard Extensions (SGX) is a set of instruction codes implementing trusted execution environment that are built into some Intel central processing units (CPUs). They allow user-level and operating system code to define protected private regions of memory, called enclaves.[1][2] SGX is designed to be useful for implementing secure remote computation, secure web browsing, and digital rights management (DRM).[3] Other applications include concealment of proprietary algorithms and of encryption keys.[4]

SGX involves encryption by the CPU of a portion of memory (the enclave). Data and code originating in the enclave are decrypted on the fly within the CPU,[4] protecting them from being examined or read by other code,[4] including code running at higher privilege levels such as the operating system and any underlying hypervisors.[1][4][2] While this can mitigate many kinds of attacks, it does not protect against side-channel attacks.[5]

A pivot by Intel in 2021 resulted in the deprecation of SGX from the 11th and 12th generation Intel Core processors, but development continues on Intel Xeon for cloud and enterprise use.[6][7]

Details

[edit]

SGX was first introduced in 2015 with the sixth generation Intel Core microprocessors based on the Skylake microarchitecture.

Support for SGX in the CPU is indicated in CPUID "Structured Extended feature Leaf", EBX bit 02,[8] but its availability to applications requires BIOS/UEFI support and opt-in enabling which is not reflected in CPUID bits. This complicates the feature detection logic for applications.[9]

Emulation of SGX was added to an experimental version of the QEMU system emulator in 2014.[10] In 2015, researchers at the Georgia Institute of Technology released an open-source simulator named "OpenSGX".[11]

One example of SGX used in security was a demo application from wolfSSL[12] using it for cryptography algorithms.

Intel Goldmont Plus (Gemini Lake) microarchitecture also contains support for Intel SGX.[13]

Both in the 11th and 12th generations of Intel Core processors, SGX is listed as "Deprecated" and thereby not supported on "client platform" processors.[6][14][15] This removed support of playing Ultra HD Blu-ray discs on officially licensed software, such as PowerDVD.[16][17][18]

List of SGX vulnerabilities

[edit]

Prime+Probe attack

[edit]

On 27 March 2017 researchers at Austria's Graz University of Technology developed a proof-of-concept that can grab RSA keys from SGX enclaves running on the same system within five minutes by using certain CPU instructions in lieu of a fine-grained timer to exploit cache DRAM side-channels.[19][20] One countermeasure for this type of attack was presented and published by Daniel Gruss et al. at the USENIX Security Symposium in 2017.[21] Among other published countermeasures, one countermeasure to this type of attack was published on September 28, 2017, a compiler-based tool, DR.SGX,[22] that claims to have superior performance with the elimination of the implementation complexity of other proposed solutions.

Spectre-like attack

[edit]
Main article: Spectre (security vulnerability)

The LSDS group at Imperial College London showed a proof of concept that the Spectre speculative execution security vulnerability can be adapted to attack the secure enclave.[23] The Foreshadow attack, disclosed in August 2018, combines speculative execution and buffer overflow to bypass the SGX.[24] A security advisory and mitigation for this attack, also called an L1 Terminal Fault, was originally issued on August 14, 2018 and updated May 11, 2021.[25]

Enclave attack

[edit]

On 8 February 2019, researchers at Austria's Graz University of Technology published findings which showed that in some cases it is possible to run malicious code from within the enclave itself.[26] The exploit involves scanning through process memory in order to reconstruct a payload, which can then run code on the system. The paper claims that due to the confidential and protected nature of the enclave, it is impossible for antivirus software to detect and remove malware residing within it. Intel issued a statement, stating that this attack was outside the threat model of SGX, that they cannot guarantee that code run by the user comes from trusted sources, and urged consumers to only run trusted code.[27]

MicroScope replay attack

[edit]

There is a proliferation of side-channel attacks plaguing modern computer architectures. Many of these attacks measure slight, nondeterministic variations in the execution of code, so the attacker needs many measurements (possibly tens of thousands) to learn secrets. However, the MicroScope attack allows a malicious OS to replay code an arbitrary number of times regardless of the program's actual structure, enabling dozens of side-channel attacks.[28] In July 2022, Intel submitted a Linux patch called AEX-Notify to allow the SGX enclave programmer to write a handler for these types of events.[29]

Plundervolt

[edit]

Security researchers were able to inject timing specific faults into execution within the enclave, resulting in leakage of information. The attack can be executed remotely, but requires access to the privileged control of the processor's voltage and frequency.[30] A security advisory and mitigation for this attack was originally issued on August 14, 2018 and updated on March 20, 2020.[31]

LVI

[edit]
Main article: Load value injection

Load Value Injection[32][33] injects data into a program aiming to replace the value loaded from memory which is then used for a short time before the mistake is spotted and rolled back, during which LVI controls data and control flow. A security advisory and mitigation for this attack was originally issued on March 10, 2020 and updated on May 11, 2021.[34]

SGAxe

[edit]

SGAxe,[35] an SGX vulnerability published in 2020, extends a speculative execution attack on cache,[36] leaking content of the enclave. This allows an attacker to access private CPU keys used for remote attestation.[37] In other words, a threat actor can bypass Intel's countermeasures to breach SGX enclaves' confidentiality. The SGAxe attack is carried out by extracting attestation keys from SGX's private quoting enclave that are signed by Intel. The attacker can then masquerade as legitimate Intel machines by signing arbitrary SGX attestation quotes.[38] A security advisory and mitigation for this attack, also called a Processor Data Leakage or Cache Eviction, was originally issued January 27, 2020 and updated May 11, 2021.[39]

ÆPIC leak

[edit]

In 2022, security researchers discovered a vulnerability in the Advanced Programmable Interrupt Controller (APIC) that allows for an attacker with root/admin privileges to gain access to encryption keys via the APIC by inspecting data transfers from L1 and L2 cache.[40] This vulnerability is the first architectural attack discovered on x86 CPUs. This differs from Spectre and Meltdown which use a noisy side channel. This exploit currently affects Intel Core 10th, 11th and 12th generations, and Xeon Ice Lake microprocessors.[41][42]

Extraction of the private key

[edit]

The code signature is generated with a private key that is only in the enclave. The private key is encoded via “fuse” elements on the chip. In the process, bits are burnt through, giving them the binary value 0. This private key cannot be extracted because it is encoded in the hardware. Mark Ermolov, Maxim Goryachy and Dmitry Sklyarov refuted the claim to trustworthiness of the SGX concept at https://github.com/chip-red-pill/glm-ucode#.

SGX malware arguments

[edit]

There has been a long debate on whether SGX enables creation of superior malware. Oxford University researchers published an article in October 2022[43] considering attackers' potential advantages and disadvantages by abusing SGX for malware development. Researchers conclude that while there might be temporary zero-day vulnerabilities to abuse in SGX ecosystem, the core principles and design features of Trusted Execution Environments (TEEs) make malware weaker than a malware-in-the-wild, TEEs make no major contributions to malware otherwise.[weasel words]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Software Guard Extensions

View on Grokipedia
from Grokipedia
Intel Software Guard Extensions (SGX) is a set of hardware-based security instructions integrated into certain Intel x86 processors, designed to create isolated execution environments known as enclaves that protect sensitive application code and data from unauthorized access, including by privileged software such as the operating system or hypervisor. Introduced in Intel's Skylake microarchitecture in 2015, SGX enables confidential computing by allocating a protected region of memory called the Enclave Page Cache (EPC), initially limited to 128 MB but expandable up to 1 TB on later hardware, where enclave contents are encrypted and isolated using hardware mechanisms like the Memory Encryption Engine (MEE). This technology supports key operations such as enclave creation (via instructions like ECREATE and EINIT), entry and exit (EENTER/EEXIT), and attestation to verify enclave integrity remotely through cryptographic measurements stored in the MRENCLAVE register. SGX's architecture relies on Processor Reserved Memory (PRM) to shield enclaves from external interference, including (DMA) attacks, while allowing multi-threading via Thread Control Structures (TCS) and handling exceptions through Asynchronous Enclave Exits (AEX) that save state in secure State Save Areas (SSA). It provides strong guarantees of , , and freshness for data in use, even in untrusted cloud environments, making it suitable for applications like secure , digital rights management, and blockchain processing. However, SGX has faced challenges, including side-channel vulnerabilities (such as cache-timing attacks) and physical attacks on DRAM, with recent 2025 disclosures like the WireTap exploit highlighting ongoing risks that have prompted mitigations and some platform migrations away from it. Development tools for SGX include the Intel SGX SDK, which offers APIs, libraries, and sample code for building enclaves on and Windows, though support has evolved with 's focus shifting toward successors like Intel Trust Domain Extensions (TDX); as of April 2025, Intel ended support for the SGX Attestation Service (IAS), with some APIs extended to 2026. Despite limitations in enclave size and performance overhead from memory encryption and eviction, SGX remains a foundational technology for hardware-rooted trusted execution, influencing standards in .

Introduction

Overview

Intel Software Guard Extensions (SGX) is a set of CPU instruction extensions introduced by to enable the creation of hardware-isolated regions known as enclaves, which protect selected code and data from access or modification by privileged software entities such as the operating system (OS) or . These enclaves operate within the processor's reserved , ensuring that even kernel-level (ring 0) or user-level (ring 3) software cannot interfere with or observe the enclave's execution. SGX represents a (TEE) that aligns with the broader paradigm of , where sensitive computations can occur on untrusted platforms without exposing data to the host environment. By leveraging hardware-enforced isolation, SGX allows applications to partition critical workloads into secure enclaves, shielding them from the rest of the system, including potential or administrative privileges. The technology provides robust isolation against software-based attacks originating from rings 0 and 3, as well as limited defenses against certain hardware threats through CPU-level access controls. Key benefits include maintaining data —preventing unauthorized disclosure—and integrity—ensuring computations remain unaltered—throughout the processing lifecycle, even in shared or cloud-based infrastructures.

Purpose and Design Goals

Intel Software Guard Extensions (SGX) were developed to address the challenges of performing sensitive computations on untrusted platforms, particularly in environments where the operating system, hypervisors, and even system administrators may be compromised. The primary purpose is to enable secure remote by creating hardware-isolated regions called enclaves, which protect and from disclosure or modification by privileged software. This allows applications to safeguard secrets such as cryptographic keys, proprietary algorithms, and user , supporting use cases like (DRM), secure web browsing, and confidential processing in infrastructure-as-a-service (IaaS) settings. The design goals of SGX emphasize strong isolation with minimal disruption to existing software ecosystems, ensuring that enclaves provide , , and freshness for enclosed without requiring changes to the underlying OS or . Key objectives include minimizing the (TCB) to the CPU package and , enabling remote attestation to verify enclave to third parties, and supporting sealing for persistent storage of secrets across enclave instances or software versions. These goals facilitate relocatable enclaves within the platform, allowing developers to build trusted execution environments that resist software-based attacks while maintaining compatibility with standard development and deployment models. Mechanisms like attestation and sealing underpin these objectives by cryptographically proving enclave trustworthiness and enabling secure persistence, respectively. SGX operates under a that assumes an untrusted software stack, including malicious OS kernels, hypervisors, , and (SMM) code, as well as potential physical adversaries capable of probing DRAM or bus traffic but not directly attacking the CPU die. It targets threats such as memory disclosure through debugging or DMA, active address translation attacks, page swapping by the OS, and tampering by privileged , while excluding side-channel attacks and physical chip manipulations. Compared to software-only isolation techniques like virtual machines or sandboxes, which rely on configurable page tables and can be bypassed by privileged software, SGX provides stronger hardware-enforced guarantees through reserved processor inaccessible to the OS, offering un-bypassable protection against both passive and active software adversaries. SGX evolved from earlier Intel security features like (TXT), which protected larger system regions using virtual machine extensions (VMX) but suffered from a broader TCB including (SMM) and vulnerability to hypervisor exploits. By contrast, SGX narrows the TCB to enclave-specific hardware mechanisms, avoiding VMX dependencies and incorporating memory encryption to defend against DRAM-based attacks, thus providing more granular and flexible protection for application-level secrets. This progression builds on trusted platform modules (TPMs) for attestation while introducing developer-centric enclaves for fine-grained isolation.

History

Development and Announcement

Intel's development of Software Guard Extensions (SGX) emerged in the post-Snowden era of , driven by revelations of that underscored the limitations of software-only security in protecting sensitive data from untrusted platforms, including operating systems, hypervisors, and providers. As part of its broader security roadmap, sought to embed hardware-based isolation directly into the processor , enabling applications to create protected enclaves for confidential computations without relying on potentially compromised . This push aligned with rising demands for secure remote execution in and enterprise environments, where traditional trust models were increasingly inadequate. SGX was first announced publicly in at the Hardware and Architectural Support for Security and Privacy (HASP) workshop, where Intel researchers introduced the technology as an extension to the Architecture for building secure enclaves with hardware-enforced attestation and sealing capabilities. The foundational paper, authored by key contributors Ittai Anati, Shay Gueron, Simon P. Johnson, and Vincent R. Scarlata from Corporation, outlined the motivations to enable remote provisioning of software and secrets over untrusted networks while mitigating attacks through isolated execution spaces. These efforts stemmed from Intel's internal architecture teams, incorporating concepts from ongoing research in trusted execution environments (TEEs) to address the expanding in modern computing devices. Further details on SGX's design were presented by Carlos Rozas of Labs on November 6, 2013, at the Parallel Data Lab's Storage Systems Day, highlighting the technology's goal to protect application secrets from malicious OS, , drivers, and virtual machine monitors through a reduced . This presentation, tied to the SOSP 2013 joint poster session, emphasized 's commitment to scalable, developer-friendly without altering existing deployment models. Development involved collaborations with academic researchers on TEE fundamentals, drawing from seminal work on hardware isolation to refine SGX's processor instructions for mainstream platforms. Pre-Skylake prototypes were explored internally during this period to validate the ahead of broader .

Release Timeline and Evolution

Software Guard Extensions (SGX) first became commercially available in 2015, integrated into Intel's 6th-generation Core processors based on the Skylake microarchitecture, marking the initial hardware implementation of the technology for client platforms. This release focused on providing basic enclave creation and execution capabilities, with support extending to server-grade Intel Xeon processors starting the same year, enabling secure workloads in data center environments. In 2016, Intel introduced SGX2 as an enhancement to the original SGX1 feature set via new instructions and programming models; hardware support became available in 2017 with the rollout of 8th-generation Core processors under the Coffee Lake microarchitecture and other platforms like Gemini Lake. SGX2 added support for dynamic enclave updates, version management, and thread management to allow more flexible runtime modifications without full enclave reinitialization. These updates addressed limitations in the initial SGX1 design, which required static enclave configurations, and expanded applicability for evolving software needs across both client and server platforms. Support for SGX continued on most and processors through 2020, with broad adoption in enterprise settings. By the 2020s, SGX evolved further through integration with broader confidential computing frameworks, such as those used in public cloud services, emphasizing hardware-rooted isolation for data-in-use protection in multi-tenant environments. Support for SGX has continued on Intel Xeon Scalable processors into the 2020s, with features like expanded enclave capacity in 3rd Gen Xeon (2021) and regular Trusted Computing Base (TCB) recovery updates, including those in 2025 addressing new vulnerabilities such as CVE-2025-20053. However, Intel issued deprecation notices for SGX on 11th- and 12th-generation Core processors in 2021, shifting focus to Xeon Scalable processors for ongoing development while maintaining legacy support on earlier generations. The accompanying (SDK) launched in 2015 alongside the initial hardware release, providing essential tools for enclave development, and has seen regular updates for compatibility and security enhancements, with versions continuing through 2025 to support and attestation protocols.

Technical Architecture

Enclaves and Enclave Page Cache (EPC)

Enclaves in Intel Software Guard Extensions (SGX) are isolated execution environments that protect sensitive code and data from unauthorized access by higher-privilege software, such as the operating system kernel or hypervisors. They operate in user mode (ring 3) but enter a special enclave mode during execution, where the processor enforces strict isolation through hardware mechanisms. This mode prevents external interference, ensuring and for enclave contents. The lifecycle of an enclave begins with creation using the ECREATE instruction, which allocates a Secure Enclave Control (SECS) in protected to define the enclave's base address, size, and attributes like debug mode. then loads code and data pages into the enclave via EADD instructions, which copy 4 KB pages from untrusted and record their permissions in an internal metadata . Initialization completes the process with the EINIT instruction, which verifies the enclave's contents against a signed (SIGSTRUCT), computes a cryptographic hash (MRENCLAVE), and transitions the enclave to an executable state, after which no further pages can be added. Enclaves are destroyed by sequentially removing pages with EREMOVE, starting from leaf pages and ending with the SECS. The Enclave Page Cache (EPC) serves as the secure physical region dedicated to storing enclave contents and metadata, consisting of 4 KB pages within a processor-reserved (PRM) area inaccessible to normal . In initial SGX implementations (SGX1), the EPC is limited to a total size of 128 MB shared across all enclaves on the system, enforced by configuration. Later processor generations, such as 3rd Gen Scalable processors, support larger EPC configurations up to 1 TB on dual-socket systems. SGX2 provides dynamic features, including secure paging of enclave pages to system memory when the EPC is full. Enclave entry and exit are mediated by specific leaf functions of the ENCLU instruction to maintain isolation. The EENTER instruction transfers control from untrusted ring 3 code to the enclave, validating a Thread Control Structure (TCS), flushing the (TLB), and setting the instruction pointer to the enclave's (OENTRY) while switching to enclave mode. Conversely, EEXIT exits the enclave, restoring control to the calling untrusted code and clearing enclave mode. Asynchronous exits occur via the AEX mechanism, triggered by interrupts, exceptions, or certain faults, which save the enclave's processor state to a designated State Save Area (SSA) in the EPC and resume execution in untrusted mode; recovery uses ERESUME to reload state and continue from the interruption point. SGX supports multi-threading within enclaves through Thread Control Structures (TCS), each occupying a dedicated 4 KB EPC page that defines an , stack base, and SSA frame for a single thread context. The number of TCS pages determines the maximum concurrent threads, with the operating system scheduling threads across logical processors while the hardware enforces isolation and coherence, such as through TLB invalidations on context switches. This model allows enclaves to leverage host parallelism without exposing thread state outside the secure boundary.

Memory Encryption Engine (MEE) and Protection Mechanisms

The Memory Encryption Engine (MEE) serves as a hardware-based extension to the in processors supporting Software Guard Extensions (SGX), providing transparent and protection for Enclave Page Cache (EPC) pages when they are stored in system DRAM outside the processor package boundary. It operates on 4KB EPC pages, encrypting their contents using AES in Counter (CTR) mode to ensure against physical attacks, while simultaneously generating a 128-byte Page Crypto Metadata (PCMD) structure that includes a Carter-Wegman MAC over the and metadata, a version counter for freshness, and additional metadata to prevent replay or tampering. In hardware supporting larger EPC sizes (such as 3rd Gen Scalable processors and later), the scheme uses AES-XTS for , with mechanisms adjusted for . This mechanism protects enclave from unauthorized disclosure or modification by entities with physical access to , such as cold-boot attacks or , without relying on software intervention. Enclaves execute in user-mode privilege level (ring 3), yet achieve strong isolation through CPU-enforced hardware protections that block direct access to EPC pages from higher-privilege software, including the operating system kernel (ring 0), hypervisors, (SMM), or peripherals via (DMA). The processor hardware monitors all memory requests to the Processor Reserved Memory (PRM) region containing the EPC, rejecting unauthorized attempts at the hardware level to maintain the enclave's security perimeter within the CPU package. This ring-agnostic enforcement ensures that even privileged code cannot inspect or alter enclave memory without explicit enclave instructions like EENTER or EEXIT. Page-level protections and tracking are managed through dedicated hardware structures, with the Enclave Control Structure (SECS) serving as a per-enclave metadata page that stores attributes such as the enclave's base address, size, and security flags, while the Enclave Page Cache Map (EPCM) maintains an entry for each EPC page to record its type (e.g., regular data or thread control structure), permissions (read, write, execute), and binding to a specific SECS. Permissions are enforced during page loads and evictions via SGX instructions like EADD and EWRT, ensuring that only the owning enclave can access its pages according to the defined rights; any mismatch, such as an attempt to write to a read-only page or access a page from a non-owner context, triggers a machine check exception. Violation handling typically results in a page fault (#PF) for blocked or invalid accesses or a general-protection fault (#GP) for permission errors, causing the CPU to abort the operation and potentially terminate the enclave to prevent compromise. The MEE's cryptographic keys are derived from hardware root secrets, including a platform-unique Fuse Key programmed into the processor during , which acts as a secure foundation for generating the 128-bit AES key and associated components without software visibility or export. These roots enable derivation of effective per-page protections through unique nonces and version counters in the CTR mode, ensuring that even with a shared base key, each EPC page's is distinct and bound to its metadata; additional enclave-specific keys for related operations can be obtained via the EGETKEY instruction, which applies a hardware using the Fuse Key hierarchy as input. This approach ties uniqueness to the physical platform, preventing key reuse across systems.

Key Security Features

Attestation

Attestation in Intel® Software Guard Extensions (SGX) enables verification of an enclave's and authenticity, confirming that the enclave's code and data remain untampered and execute within a genuine SGX environment. This process relies on cryptographic reports generated by the hardware, which include measurements of the enclave's contents and platform state. and remote attestation serve distinct purposes, with focusing on intra-platform verification and remote enabling trust establishment across untrusted networks. Local attestation allows enclaves on the same platform to mutually verify each other without external involvement. It uses the EREPORT instruction to generate a cryptographic report from within an enclave, which includes the target enclave's identity (via sgx_target_info_t) and user-specified data (via sgx_report_data_t). The report is verified by the target enclave using the , which checks the report's derived from a shared key obtained through the EGETKEY instruction. This shared key is computed based on common parameters such as the enclave's MRENCLAVE or MRSIGNER, ensuring only between matching enclaves on the same SGX-enabled CPU. Remote attestation extends local attestation to allow verification by off-platform parties. Previously, this involved Intel's Enhanced Privacy ID (EPID) infrastructure, where a local report from EREPORT was passed to a Quoting Enclave to generate an EPID-signed quote, which was then submitted to Intel's Attestation Service (IAS) for validation of the platform's trustworthiness, enclave measurements, and security revision level. EPID provided group-based anonymity to prevent linking attestations to specific platforms. However, Intel end-of-lifed EPID-based IAS on April 2, 2025. Current remote attestation uses (ECDSA) mechanisms via Attestation Primitives (DCAP). A local report from EREPORT is passed to a Quoting Enclave, which uses EGETKEY to derive an attestation key and converts the report into an ECDSA-signed quote using individual platform keys provisioned via Intel's Provisioning Certification Service (PCS). The verifies the quote against platform collateral (certificates and root CA lists) obtained from PCS, confirming the platform's trustworthiness, enclave measurements, and revision level. ECDSA supports unlinkable signatures for in environments while allowing direct platform identification when needed. The SGX report format, embedded in both local reports (sgx_report_t) and remote quotes (sgx_quote_t), standardizes the verifiable . It comprises a header with CPU version (CPUSVN) and enclave version (ISVSVN), followed by the body containing MRENCLAVE—a 256-bit SHA-256 hash measuring the enclave's initial and for —and MRSIGNER, a 256-bit hash of the signing authority's key for authenticity. Additional fields include attributes (sgx_attributes_t) specifying enclave properties like debug mode, initialization status, and provisioning key access, as well as a 64-byte report_data field for application-specific binding. These elements collectively bind the report to the enclave's runtime state and platform configuration. In SGX2, attestation is enhanced with native ECDSA support via APIs like sgx_get_quote_ex, improving scalability by allowing attestation services independent of Intel's EPID infrastructure, such as through the Data Center Attestation Primitives (DCAP). This enables enterprises to deploy custom verification without relying on centralized services, while maintaining compatibility with EPID for legacy deployments. ECDSA quotes use individual platform keys provisioned via the Provisioning Certification Service, supporting unlinkable signatures for privacy in cloud environments.

Sealing

Sealing in Intel Software Guard Extensions (SGX) enables enclaves to securely store sensitive data outside protected memory for persistence, ensuring confidentiality and integrity through cryptographic encryption. The process involves encrypting the data using a sealing key derived via the EGETKEY instruction, which generates a 128-bit symmetric key based on enclave-specific attributes and platform secrets. This key is used to encrypt the data, often in conjunction with a (MAC) computed via AES-GMAC to verify integrity upon retrieval. Selective unsealing allows the data to be decrypted only by authorized enclaves matching the specified , preventing unauthorized access even if the storage medium is compromised. The key hierarchy for sealing begins with a root sealing key stored in the processor's e-fuses, a hardware-protected area inaccessible to software, which is then combined with enclave identity values to derive the final sealing key. EGETKEY incorporates inputs such as the CPU Security Version Number (CPUSVN), the enclave's measurement hash (MRENCLAVE), or the signer's identity (MRSIGNER), along with the ISV Security Version Number (ISVSVN) and an attribute mask. MRENCLAVE policy binds the key to the exact enclave code and data configuration, ensuring sealed data is accessible only to identical enclave instances, while MRSIGNER policy ties it to the signing authority, permitting access across enclaves signed by the same entity, including updated versions if ISVSVN permits. This hierarchy also includes the SGX Owner Epoch, a platform-specific value that further binds the key to the current system ownership. Within the enclave lifecycle, sealing supports persisting state across system reboots, enclave crashes, or reloads by storing encrypted data in outside the Enclave Page Cache (EPC), allowing retrieval without re-provisioning secrets. For instance, cryptographic keys or user credentials can be sealed for later use in the same enclave on the same platform, with the MAC ensuring no tampering has occurred during storage. This mechanism integrates with attestation processes for deriving shared keys in distributed scenarios, but sealing itself focuses on local persistence. Limitations of SGX sealing include its binding to the specific CPU and platform through elements like CPUSVN and e-fuse secrets, which prevents across different systems without additional mechanisms. In SGX1, sealed data is strictly non-migratable, while SGX2 introduces features like enclave migration via EMODPE instructions, allowing limited transfer between compatible platforms after re-sealing, though this requires careful version management to avoid incompatibility.

Implementation and Development

Supported Hardware Platforms

Software Guard Extensions (SGX) was initially introduced on client platforms with Intel's 6th Generation Core processors based on the Skylake microarchitecture in 2015. Support extended through subsequent generations, including Kaby Lake, Coffee Lake, and up to the 10th Generation Core processors under the Comet Lake codename in 2019. However, SGX functionality was deprecated starting with the 11th Generation Rocket Lake processors in 2021 and fully discontinued in all subsequent consumer Core generations, reflecting Intel's shift away from SGX in client hardware. On the server side, SGX found broader and more sustained adoption beginning with the first-generation Scalable processors on the Purley platform in 2017, which were based on the Skylake-SP microarchitecture. This support has continued across subsequent Scalable generations, encompassing the second-generation (2019), third-generation Ice Lake (2021), fourth-generation processors released in 2023, fifth-generation (2023), and sixth-generation Granite Rapids processors (2024-2025). Additionally, specialized families such as , Xeon E, and CPU Max series also incorporate SGX capabilities for edge and embedded applications. The Enclave Page Cache (EPC), which provides the protected memory region for SGX enclaves, has a standard size of 128 MB on most supported processors, with approximately 96 MB available for enclave use after overhead. In enterprise configurations, particularly with third-generation and later Scalable processors, the maximum EPC size can be expanded significantly through hardware configuration fuses set during , reaching up to 512 GB per socket—enabling up to 1 TB total in a two-socket system. As of November 2025, SGX remains actively supported in environments through ongoing processor deployments, while consumer client CPUs have seen full phase-out, limiting new hardware availability for desktop and laptop use. Cloud providers continue to offer SGX-enabled instances for enterprise workloads, such as Azure's DC-series virtual machines powered by compatible hardware.

Software Development Kit (SDK) and Tools

The SGX (SDK) provides a comprehensive set of APIs, libraries, tools, and documentation for developers to create and manage secure enclaves on supported platforms, including Windows and operating systems. It enables the partitioning of applications into trusted (enclave) and untrusted (host) components, facilitating the protection of sensitive code and data. The SDK is available for download from Intel's official repositories and supports both hardware-based execution and environments. A core component of the SDK is the Edger8r tool, which bridges trusted and untrusted code by processing Enclave Definition Language (EDL) files to generate interface proxies for enclave calls (ECALLs) and host calls (OCALLs). For instance, running sgx_edger8r [options] <file.edl> produces trusted-side files like demo_t.h and demo_t.c for ECALL implementations, and untrusted-side files like demo_u.h and demo_u.c for proxy functions, supporting data attributes such as [in, out, string] for secure parameter passing. This tool ensures type-safe communication between enclave and host code while minimizing attack surfaces. The SDK includes essential libraries for runtime support, such as the SGX Driver, which handles low-level hardware interactions like enclave creation and destruction via functions such as sgx_create_enclave and sgx_destroy_enclave. Complementing this is the Platform Software (PSW), a collection of services and libraries—including sgx_urts.dll, sgx_tservice.lib, and the AESM (Attestation Service) daemon—that provide enclave management, quoting, and attestation capabilities. The PSW is installed system-wide and updated periodically, with version 2.26 released in May 2025 incorporating security fixes and upgrades to like Integrated Performance Primitives (IPP) for enhanced security. Note that the SGX Attestation Service (IAS) ended support on April 2, 2025, with developers encouraged to migrate to the Provisioning Service (PCS) for attestation, whose API versions 2 and 3 have EOL extended to April 30, 2026. For development on systems lacking SGX hardware, the SDK offers a simulation mode that emulates enclave behavior using software-based libraries such as sgx_trts_sim.lib and sgx_urts_sim.lib, requiring only 4.1 support. This mode, activated in Debug or Prerelease configurations, allows testing of enclave logic without hardware isolation, though it returns errors like SGX_ERROR_MODE_INCOMPATIBLE (0x200E) when hardware-specific features are invoked. The development workflow begins with building the enclave using the SDK's build tools, followed by signing to ensure integrity. Signing employs the sgx_sign utility with a private key, supporting one-step signing (e.g., sgx_sign sign -enclave enclave.dll -key private.pem) or two-step processes involving data generation and signature concatenation, configured via an XML file specifying parameters like Product ID. For , enclaves are built in debug mode with SGX_DEBUG_FLAG set to TRUE, then inspected using GDB extensions like the sgx-gdb plugin, which supports breakpoints inside enclaves and commands for thread control, though some standard GDB features are unavailable. This requires debug symbols from packages like libsgx-enclave-common-dbgsym. Third-party tools like the Open Enclave SDK enhance portability by abstracting SGX-specific APIs for cross-Trusted Execution Environment (TEE) development, supporting SGX alongside other hardware like ARM TrustZone, with ongoing updates for compatibility. has issued SDK updates through 2025 to address vulnerabilities, including fixes for edger8r input validation issues (INTEL-SA-01383) and out-of-bounds writes (CVE-2024-34776), as well as additional advisories like INTEL-SA-01213.

Applications and Adoption

Primary Use Cases

Software Guard Extensions (SGX) primarily enables secure remote computation by allowing applications to execute sensitive operations in isolated enclaves on untrusted cloud infrastructure, ensuring data privacy without relying on the provider's trustworthiness. This is particularly valuable for processing confidential information, such as , where patient records can be analyzed for insights like disease patterns while keeping personally identifiable information (PII) encrypted and inaccessible to the host system or external parties. For instance, enclaves facilitate multi-party computation protocols that aggregate data from multiple sources without exposing individual inputs, as demonstrated in frameworks leveraging SGX for privacy-preserving . In (DRM), SGX protects media decryption keys and playback logic within browser or media player enclaves, preventing unauthorized access even if the underlying operating system is compromised. This hardware-enforced isolation ensures that content providers can securely deliver protected media streams over untrusted networks, with keys remaining confined to the enclave during decryption processes. Such applications align with SGX's design for safeguarding in consumer software environments. SGX supports cryptographic operations by providing a trusted environment for , , and attestation, which is essential for systems like nodes and virtual private networks (VPNs). In contexts, enclaves can securely handle private keys and perform transaction signing without exposure to the host, enabling confidential execution. For VPNs, SGX enclaves manage session keys and authentication tokens, ensuring integrity against potential platform-level attacks. These uses leverage SGX's attestation mechanisms to verify enclave integrity remotely, establishing trust for distributed systems. For confidential databases, SGX enables of sensitive , such as PII in key-value stores adapted from systems like , by encrypting data at rest and in transit while decrypting only within the enclave for queries. This approach allows database operations on untrusted servers without risking leakage, supporting use cases in or customer analytics where compliance with privacy regulations like GDPR is critical. Enclaves thus transform traditional databases into secure, tamper-resistant components for handling regulated information.

Notable Deployments and Industry Adoption

has been a pioneer in SGX integration within its platform, offering DC-series virtual machines that leverage SGX enclaves to protect data in use. These capabilities were first made available in preview in 2018 in regions like East US and West Europe, with general availability of DCsv2-series instances in 2020, allowing developers to deploy enclaves for sensitive applications without modifying existing code. IBM Cloud provides robust SGX-based confidential computing through its Virtual Servers for VPC and bare metal offerings, utilizing 4th Gen Intel Xeon processors with built-in SGX support to create hardware-isolated enclaves for data protection. This enables enterprises to run workloads in trusted environments, with features like attestation and sealing integrated into IBM's ecosystem for hybrid cloud deployments. In the blockchain domain, SGX has facilitated private transactions in Ethereum clients through enclave-based execution of nodes like Geth, as demonstrated in research prototypes that protect transaction data from external visibility while maintaining blockchain integrity. Similarly, Hyperledger Fabric employs SGX via its Fabric Private Chaincode (FPC) framework, which executes smart contracts in enclaves to ensure confidentiality of inputs, outputs, and state data across distributed networks. Adoption in has centered on SGX for (MPC), where enclaves enable collaborative analytics on sensitive data without revealing individual inputs, as explored in frameworks that combine SGX with MPC protocols to support detection and modeling. IBM's SGX offerings further extend this to financial workloads, while Google Cloud's services, though primarily based on AMD SEV and Intel TDX, complement SGX ecosystems through partnerships for hybrid secure computations. As of 2025, industry trends indicate a shift toward multi-TEE standards that incorporate SGX alongside alternatives like SEV-SNP and TDX, driven by the need for interoperable solutions amid growing data regulations. The overall market is projected to expand significantly, from approximately $9.31 billion in 2025 to $115.54 billion by 2030, with SGX remaining a foundational in enclave-based deployments despite evolving competition.

Security Vulnerabilities

Side-Channel and Speculative Execution Attacks

Software Guard Extensions (SGX) provides strong isolation for enclaves, but it remains susceptible to side-channel attacks that exploit timing differences, cache behaviors, and other microarchitectural features to infer sensitive data without directly accessing enclave memory. These attacks leverage shared hardware resources between enclaves and untrusted software, such as the operating system or , to observe patterns in resource usage that reveal secrets like cryptographic keys. Speculative execution attacks, a subset of these, abuse the CPU's and prediction mechanisms to transiently access and leak enclave data before it is squashed. Cache-based side-channel attacks on SGX target the last-level cache (LLC) to monitor enclave access patterns. In 2017, researchers demonstrated the Prime+Probe technique from a malicious enclave to extract AES keys from a victim enclave by measuring cache contention; the attack achieves a success rate of over 99% in recovering key bytes after observing thousands of encryptions. This approach exploits the fact that SGX does not isolate cache sets between enclaves, allowing precise timing of eviction and probing to reconstruct data-dependent accesses. Building on similar principles, the SGAxe attack in 2020 combined CacheOut speculation with handling flaws to extract SGX sealing and attestation keys from Intel's Quoting Enclave, enabling attackers to forge remote attestations. Speculative execution vulnerabilities further compromise SGX by allowing transient data leaks during mispredicted branches or loads. The SgxPectre attacks, introduced in 2018, adapt Spectre variant 1 to SGX by poisoning branch predictors from outside the enclave, leading to speculative reads of enclave secrets like the sealing key; extraction requires about 2,000 samples per byte with a 96% success rate. Similarly, the Load Value Injection (LVI) attack from 2020 injects poisoned data into the load pipeline to mislead , bypassing SGX barriers to leak up to 4 KB of enclave memory per injection, including ECDSA private keys in under 10 minutes on vulnerable hardware. These attacks highlight how SGX's reliance on hardware-enforced boundaries fails against CPU speculation that temporarily ignores them. Additional side-channels exploit other microarchitectural features for leakage. The replay attack, presented in 2019, enables adversaries to replay noisy microarchitectural states in SGX enclaves using nonce reuse in deterministic replay mechanisms, denoising cache side-channels to recover full AES keys with high fidelity after amplifying signals over multiple runs. In 2022, the ÆPIC Leak demonstrated an architectural vulnerability in the (APIC) that leaks uninitialized data from the , including stale enclave payloads, without relying on traditional side-channels; this affects SGX on 10th- to 12th-generation CPUs and can disclose up to 64 bytes per . The impacts of these attacks are severe, with key extraction times ranging from seconds to 10 hours depending on the target and hardware, potentially compromising entire enclave ecosystems like remote attestation. Mitigations include disabling (TSX) to curb speculation, enforcing constant-time implementations to eliminate timing leaks, and 's microcode updates that restrict speculative access to enclave pages. Developers are advised to use SGX SDK countermeasures like randomized memory layouts, though full protection requires ongoing hardware patches.

Physical and Hardware-Based Attacks

Physical and hardware-based attacks on Intel Software Guard Extensions (SGX) exploit the enclave's reliance on hardware isolation by requiring direct access to the processor, memory bus, or power supply, potentially compromising the Enclave Page Cache (EPC) and exposing sensitive data such as cryptographic keys. These attacks differ from remote software exploits by necessitating physical proximity or specialized equipment, targeting vulnerabilities in the underlying hardware mechanisms like memory encryption and fault tolerance. One early example of voltage manipulation is the Plundervolt attack, disclosed in 2019, which induces computational faults in SGX enclaves through undervolting. By abusing an undocumented voltage scaling interface, a privileged adversary can precisely control the CPU's supply voltage to cause bit flips in enclave computations, enabling that corrupts integrity checks or reveals secrets without directly accessing the EPC. This attack, assigned CVE-2019-11157, was demonstrated to extract RSA keys from within enclaves by inducing errors during decryption operations. Physical probing techniques have also targeted SGX's memory protections, as seen in the attack from 2018, which leverages (DMA) to access the EPC. exploits transient out-of-order execution to read enclave memory pages, allowing extraction of attestation keys and other secrets stored in SGX enclaves on affected processors. Assigned CVE-2018-3615, this attack bypasses SGX's memory encryption by mapping EPC pages into the attacker's via DMA, demonstrating how hardware interfaces intended for legitimate use can be repurposed for unauthorized access. More recent physical attacks in 2025 have intensified scrutiny on SGX's DRAM interactions. The TEE.Fail attack, published in October 2025, uses a low-cost hardware interposer (estimated at $1,000) to intercept DDR5 bus traffic and analyze deterministic encryption patterns, enabling extraction of secrets such as attestation keys from SGX enclaves on processors (4th generation and later). This compromises confidentiality in environments despite prior mitigations. In parallel, the WireTap attack, also disclosed in October 2025, eavesdrops on the DDR4 memory bus to extract ECDSA keys from SGX enclaves. By inserting a passive between the CPU and DDR4 DIMMs, researchers from and Purdue demonstrated the interception of unencrypted memory traffic, allowing reconstruction of (ECDSA) private keys used in SGX attestation. This hardware-based exploits the lack of bus-level in older DDR4 systems, succeeding in under 24 hours with off-the-shelf equipment and posing risks to and financial applications relying on SGX. Additionally, CVE-2025-26403, reported in August 2025, reveals an out-of-bounds write in the subsystem of certain 6 processors when SGX is enabled. This flaw allows a privileged local attacker to escalate privileges by writing beyond allocated bounds in the EPC management logic, potentially corrupting enclave integrity or leaking data. Affecting systems with SGX or TDX configurations, it underscores hardware-level handling weaknesses exploitable via physical or high-privilege access. Intel has responded to these physical threats with mitigations including firmware updates to enhance and memory fault detection, as well as hardware revisions in newer processor generations that incorporate stronger bus and anti-hammering protections. In 2025 advisories, Intel emphasized that such attacks fall outside the SGX threat model assuming , recommending deployment on tamper-resistant hardware and regular patches to address specific CVEs like those in 6 series. Ongoing research continues to evolve defenses, such as randomized addressing to thwart interposer-based .

Criticisms and Limitations

Potential for Malware Exploitation

Software Guard Extensions (SGX) provide strong isolation for code execution within enclaves, which inadvertently enables attackers to hide malicious payloads from traditional detection mechanisms, as the enclave's is encrypted and inaccessible to the operating system and . This isolation allows to persist undetected, evading OS-level defenses that rely on scanning user-space or monitoring system calls. In a 2019 study, researchers demonstrated the feasibility of practical enclave remaining stealthy even against advanced endpoint detection tools by executing sensitive operations entirely within the protected enclave environment. Attackers can exploit SGX by creating signed malicious enclaves that perform or initiate side-channel attacks on co-located enclaves, leveraging the hardware's trust mechanisms to appear benign. For instance, the Malware Guard Extension (MGE) framework, introduced in 2020, illustrates how adversaries can conceal cache-based side-channel attacks within an SGX enclave, bypassing defenses that monitor external software behavior while extracting cryptographic keys from victim processes. Such signed enclaves can spoof remote attestation to gain trust from other systems, enabling persistent access to sensitive data without triggering alerts from host-level security tools. Despite these advantages, SGX's design imposes limitations on malware exploitation, such as the constrained size of the Enclave Page Cache (EPC), typically limited to 128 MB, which restricts the scale of payloads and complicates large-scale malicious operations.

Performance Overhead and Usability Challenges

Software Guard Extensions (SGX) impose notable performance overheads stemming from the architectural necessities of secure execution. Transitions between trusted enclave code and untrusted host code, via enclave calls (ECALLs) and outside calls (OCALLs), require context switches that can consume thousands of CPU cycles each, contributing to significant application slowdowns in scenarios with frequent crossings. Additionally, enclave encryption and decryption processes add latency, as leaving the CPU perimeter is protected against external observation, further exacerbating costs in memory-intensive workloads. The Enclave Page Cache (EPC), SGX's protected region, introduces further overhead when exhausted. With a typical capacity of 128 MB—yielding about 93 MB usable for applications—exceeding this limit triggers page evictions to untrusted system , each operation averaging 12,000 cycles and imposing 28-65% additional slowdown, particularly in virtualized setups. These evictions not only degrade throughput but also amplify vulnerability to timing-based side effects, limiting SGX's viability for applications with expanding footprints. Usability challenges in SGX development arise from the mandatory partitioning of code into trusted (enclave-resident) and untrusted (host) components, requiring developers to redesign applications, meticulously validate data at boundaries, and manage restricted interfaces to avoid leaks. This split complicates and , as trusted operates in isolation without direct access to system services. Moreover, SGX's confinement to x86 processors hinders portability, preventing seamless deployment on non- hardware or cross-platform environments without substantial rework. As of 2025, has announced the end-of-life for several SGX services, including the SGX Attestation Service in April 2025 and TCB signing certificates in May 2025, further limiting long-term usability and prompting migrations to successor technologies like TDX. Scalability limitations compound these issues, as the fixed 128 MB EPC proves insufficient for large-scale applications, often necessitating memory optimizations or hybrid designs that dilute SGX's security benefits. Native absence of GPU support and direct I/O paths restricts acceleration for parallel or data-heavy tasks, forcing reliance on CPU-only execution and indirect host mediation, which reintroduces overheads. As of 2025, mitigation efforts like the Graphene-SGX library OS enable running unmodified applications in enclaves with overheads comparable to manual shims, facilitating easier ; however, broader adoption lags owing to entrenched development complexity and hardware constraints.

References

  1. https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/overview.html
  2. https://eprint.iacr.org/2016/086.pdf
  3. https://www.intel.com/content/www/us/en/support/articles/000059614/processors/intel-xeon-processors.html
  4. https://thehackernews.com/2025/10/new-wiretap-attack-extracts-intel-sgx.html
  5. https://community.intel.com/t5/Intel-Software-Guard-Extensions/IAS-End-of-Life-Announcement/td-p/1545831
  6. https://community.intel.com/t5/Intel-Software-Guard-Extensions/Intel-PCS-API-versions-2-and-3-EOL-Date-Extended-to-April-30/m-p/1704170
  7. https://www.intel.com/content/dam/develop/external/us/en/documents/332680-001-720907.pdf
  8. https://people.csail.mit.edu/devadas/pubs/part_2.pdf
  9. https://www.intel.com/content/dam/develop/external/us/en/documents/hasp-2013-innovative-technology-for-attestation-and-sealing-413939.pdf
  10. https://www.pdl.cmu.edu/SDI/2013/slides/rozas-SGX.pdf
  11. https://www.intel.com/content/dam/develop/external/us/en/documents/329298-002-629101.pdf
  12. https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions-processors.html
  13. https://dl.acm.org/doi/10.1145/2948618.2954331
  14. https://www.intel.com/content/www/us/en/security/confidential-computing.html
  15. https://www.intel.com/content/www/us/en/processors/xeon/third-gen-xeon-scalable-processors.html
  16. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sgxs-00107.html
  17. https://community.intel.com/t5/Intel-Software-Guard-Extensions/Intel-SGX-deprecated-in-11th-Gen-processors/m-p/1353272
  18. https://download.01.org/intel-sgx/Releases/
  19. https://download.01.org/intel-sgx/latest/linux-latest/docs/Intel_SGX_Developer_Guide.pdf
  20. https://www.intel.com/content/dam/develop/external/us/en/documents/intelsgxenclavelifecycle.pdf
  21. https://www.intel.com/content/www/us/en/content-details/671178/intel-software-guard-extensions-intel-sgx-support-for-dynamic-memory-management-inside-an-enclave.html
  22. https://www.kernel.org/doc/html/next/x86/sgx.html
  23. https://cdrdv2-public.intel.com/671508/sgx-sdk-developer-reference-for-windows-os.pdf
  24. https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html
  25. https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-intel-sgx-sealing.html
  26. https://www.intel.com/content/www/us/en/support/articles/000028173/processors.html
  27. https://www.quora.com/Why-did-Intel-discontinue-the-SGX-instruction-set-after-the-10th-generation-processors-The-cryptographic-software-I-use-relies-on-SGX-so-I-can-t-upgrade-to-newer-than-a-Comet-Lake-CPU
  28. https://www.bleepingcomputer.com/news/security/new-intel-chips-wont-play-blu-ray-disks-due-to-sgx-deprecation/
  29. https://www.intel.com/content/www/us/en/products/platforms/details/purley.html
  30. https://codentium.com/setting-up-intel-sgx/
  31. https://openmetal.io/resources/blog/intel-tdx-and-sgx-requirements/
  32. https://learn.microsoft.com/en-us/azure/confidential-computing/confidential-computing-enclaves
  33. https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/linux-overview.html
  34. https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/get-started.html
  35. https://cdrdv2-public.intel.com/671282/180309-sgx-sdk-developer-guidance-edger8r.pdf
  36. https://github.com/intel/linux-sgx
  37. https://download.01.org/intel-sgx/sgx-linux/2.11/docs/Intel_SGX_Developer_Reference_Linux_2.11_Open_Source.pdf
  38. https://www.intel.com/content/dam/develop/external/us/en/documents/overview-signing-whitelisting-intel-sgx-enclaves.pdf
  39. https://www.intel.com/content/www/us/en/content-details/671101/debugging-intel-software-guard-extensions-intel-sgx-enclaves-for-linux-operating-system.html
  40. https://download.01.org/intel-sgx/latest/linux-latest/docs/Intel_SGX_SW_Installation_Guide_for_Linux.pdf
  41. https://github.com/openenclave/openenclave
  42. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01383.html
  43. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01213.html
  44. https://cdrdv2-public.intel.com/671564/intel-sgx-platform-services.pdf
  45. https://builders.intel.com/docs/networkbuilders/intel-software-guard-extensions-intel-sgx-key-management-reference-application-kmra-on-intel-xeon-processors-technology-guide-1658482773.pdf
  46. https://learn.microsoft.com/en-us/azure/confidential-computing/virtual-machine-solutions-sgx
  47. https://azure.microsoft.com/en-us/blog/dcsv2series-vm-now-generally-available-from-azure-confidential-computing/
  48. https://www.ibm.com/solutions/confidential-computing
  49. https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-intel-sgx
  50. https://arxiv.org/abs/2204.09864
  51. https://collective.flashbots.net/t/running-geth-within-sgx-our-experience-learnings-and-code-flashbots/938
  52. https://github.com/hyperledger/fabric-private-chaincode
  53. https://research.ibm.com/projects/fabric-private-chaincode
  54. https://www.mordorintelligence.com/industry-reports/confidential-computing-market
  55. https://cloud.google.com/security/products/confidential-computing
  56. https://arxiv.org/pdf/2006.13598
  57. https://arxiv.org/abs/1702.08719
  58. https://sgaxe.com/files/SGAxe.pdf
  59. https://arxiv.org/abs/1802.09085
  60. https://gruss.cc/files/lvi.pdf
  61. https://www.cs.cmu.edu/~dskarlat/publications/microScope_isca19.pdf
  62. https://www.usenix.org/system/files/sec22-borrello.pdf
  63. https://plundervolt.com/doc/plundervolt.pdf
  64. https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-van_bulck.pdf
  65. https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2025-10-28-001.html
  66. https://thehackernews.com/2025/10/new-teefail-side-channel-attack.html
  67. https://nvd.nist.gov/vuln/detail/CVE-2025-26403
  68. https://www.intel.com/content/www/us/en/developer/articles/news/more-information-encrypted-memory-frameworks.html
  69. https://www.usenix.org/system/files/raid2019-weiser.pdf
  70. https://arxiv.org/abs/1902.03256
  71. https://cybersecurity.springeropen.com/articles/10.1186/s42400-019-0042-y
  72. https://cdrdv2-public.intel.com/671502/intel-sgx-performance-considerations.pdf
  73. https://hal.science/hal-02947792v1/document
  74. https://dl.acm.org/doi/fullHtml/10.1145/3533737.3535098
  75. https://arxiv.org/pdf/2205.06415
  76. https://www.khoury.northeastern.edu/home/amirali/publications/SGX_VB_2016.pdf
  77. https://community.intel.com/legacyfs/online/drupal_files/managed/33/70/intel-sgx-developer-guide.pdf
  78. https://www.cs.cmu.edu/~rdriley/research/pubs/iiswc2020.pdf
  79. https://par.nsf.gov/servlets/purl/10472303
  80. https://www.usenix.org/conference/atc17/technical-sessions/presentation/tsai
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.