An ECALL (Enclave Call) is a controlled entry point that allows untrusted application code to invoke a trusted function inside an enclave, forming the strictly defined interface between the protected and unprotected execution environments. It is the sole mechanism for transitioning from the host application into the hardware-isolated memory region, ensuring that the enclave's integrity and confidentiality are never compromised by arbitrary code execution.
Glossary
ECALL
A controlled entry point that allows untrusted application code to invoke a trusted function inside a hardware-enforced enclave, forming the strictly defined interface between protected and unprotected execution environments.
ENCLAVE INTERFACE
What is ECALL?
An ECALL is the strictly controlled, hardware-enforced entry point that allows untrusted application code to invoke a trusted function executing inside a secure enclave.
During an ECALL, the processor performs a context switch that saves the untrusted state, verifies the call targets a valid entry point defined in the enclave's Trusted Computing Base (TCB), and transfers execution to the protected function. Parameters are deep-copied into enclave memory to prevent Time-of-Check-to-Time-of-Use (TOCTOU) attacks, and the return value is similarly marshaled back to the untrusted buffer only after the trusted function completes.
ENCLAVE INTERFACE
Key Characteristics of ECALLs
ECALLs form the strictly controlled, hardware-enforced bridge between an untrusted host application and a trusted enclave. Each characteristic below defines a critical security or architectural property of this interface.
01
Strictly Defined Bridge Function
An ECALL is the only mechanism for untrusted code to invoke a trusted function inside an enclave. It acts as a controlled entry point, defined at compile time within the enclave's interface definition. The enclave exposes a fixed table of ECALLs; the host cannot call arbitrary code inside the protected memory region. This ensures the attack surface is limited to a small, auditable set of functions, preventing the host from hijacking the enclave's control flow.
02
Hardware-Enforced Context Switching
When an ECALL is invoked, the CPU performs a hardware-level context switch into the enclave's protected memory. Key aspects of this transition:
- Processor state is saved and cleared to prevent data leaks.
- The CPU enters enclave mode, where memory access is strictly partitioned.
- Any attempt by the host OS or hypervisor to read enclave memory during execution triggers a hardware fault. This guarantees that the trusted function executes in complete isolation from all higher-privileged software layers.
03
Deep Copy Parameter Marshaling
Parameters passed via an ECALL are deep-copied into the enclave's private memory, not shared by reference. This prevents Time-of-Check to Time-of-Use (TOCTOU) attacks where a malicious host modifies data after validation but before use. The marshaling logic:
- Allocates memory inside the enclave.
- Copies the caller's data byte-for-byte.
- Validates pointers to ensure they point outside the enclave, preventing the host from passing an internal enclave address to corrupt protected state.
04
Thread Identity and Synchronization
ECALLs execute within the context of the calling host thread, but the enclave maintains its own Thread Control Structure (TCS) for each logical thread. This binding ensures:
- The enclave can manage its own thread-local storage securely.
- Synchronization primitives like enclave-internal mutexes operate correctly without trusting the host OS scheduler.
- The enclave can detect and reject unauthorized re-entrant calls from the same thread, preventing deadlock-based denial-of-service attacks.
05
Return Value Integrity
Upon completion, the ECALL returns execution to the untrusted host with a defined return code. The hardware ensures that:
- All enclave register state is scrubbed before the host regains control.
- The return value is written to a host-accessible memory location only after the enclave exits.
- If the enclave detects an internal error or a violation, it can abort the enclave entirely, destroying its memory and sealing keys, rather than returning corrupted data to the caller.
06
Complementary Relationship with OCALLs
An ECALL (Entry Call) is the inverse of an OCALL (Outside Call). While an ECALL allows the host to enter the enclave, an OCALL allows the enclave to temporarily exit to request services from the untrusted host, such as file I/O or network access. This pairing creates a strictly bidirectional, auditable interface. The enclave must treat all data returned from an OCALL as untrusted and re-validate it, maintaining the security boundary even when interacting with the outside world.
ECALL ESSENTIALS
Frequently Asked Questions
Clear answers to the most common questions about the interface between untrusted applications and trusted enclave code.
An ECALL (Enclave Call) is a strictly defined, controlled entry point that allows untrusted application code to invoke a trusted function inside a hardware-isolated enclave. It forms the sole bridge from the unprotected execution environment into the protected memory region. When an ECALL is invoked, the processor performs a context switch: it saves the untrusted application's state, verifies the call targets a valid entry point defined in the enclave's metadata, and transitions execution to the trusted function. The parameters are deep-copied into protected memory to prevent Time-of-Check to Time-of-Use (TOCTOU) attacks. Once inside, the function executes with full confidentiality guarantees, and upon completion, the return value is copied back out to untrusted memory before the processor resumes the application's normal execution flow.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read moreENCLAVE INTERFACE COMPARISON
ECALL vs. OCALL: The Two-Way Trust Boundary
A comparison of the two controlled transition functions that form the strictly defined interface between the trusted enclave and the untrusted host application.
| Feature | ECALL | OCALL |
|---|---|---|
Direction | Untrusted → Trusted | Trusted → Untrusted |
Caller | Host application | Enclave code |
Callee | Enclave function | Host function |
Primary purpose | Invoke trusted logic | Request system services |
Memory access during call | Enclave memory accessible | Enclave memory inaccessible |
Return value trust | Trusted | Untrusted (must validate) |
Defined in | Enclave Definition Language (EDL) | Enclave Definition Language (EDL) |
Required for I/O |
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us