ELASTIC D1.1: Wasm and eBPF Landscape
Abstract
This deliverable shows a comprehensive overview of the current landscape of Wasm and eBPF technologies, including their capabilities, limitations, and use cases. It shows the existing state-of-the-art in WebAssembly (Wasm) and WebAssembly System Interface (WASI) standards, Wasm runtime implementations, support for networking and file systems within those, and eBPF project implementations and best practices. Additionally, it investigates XDP low-latency features and limitations. It covers topics such as the security and performance of Wasm runtimes, the use of Wasm in serverless computing and cloud environments, the integration of eBPF with container orchestration systems like Kubernetes, and the use of XDP for low-latency networking applications. Furthermore, it explores the potential use cases for these technologies in the context of 6G service implementation and deployment - for example, how Wasm and eBPF can be used to enable secure and efficient execution of collaborative AI and federated machine learning (ML) models in Trusted Execution Environments (TEEs) or to provide low-latency networking features for edge computing applications. It ends with future directions of these novel technologies and an initial overview of the ELASTIC architecture and components that we are developing to achieve the project objectives.
Full text
Horizon Europe Framework Programme HORIZON JU Research and Innovation Action Reliable Services and Smart Security Efficient, portabLe And Secure orchesTration for reliable servICes D1.1: Wasm and eBPF Landscape Abstract: This deliverable shows a comprehensive overview of the current landscape of Wasm and eBPF technologies, including their capabilities, limitations, and use cases. It shows the existing state-of-the-art in WebAssembly (Wasm) and WebAssembly System Interface (WASI) standards, Wasm runtime implementations, support for networking and file systems within those, and eBPF project implementations and best practices. Additionally, it investigates XDP low-latency features and limitations. It covers topics such as the security and performance of Wasm runtimes, the use of Wasm in serverless computing and cloud environments, the integration of eBPF with container orchestration systems like Kubernetes, and the use of XDP for low-latency networking applications. Furthermore, it explores the potential use cases for these technologies in the context of 6G service implementation and deployment - for example, how Wasm and eBPF can be used to enable secure and efficient execution of collaborative AI and federated machine learning (ML) models in Trusted Execution Environments (TEEs) or to provide low-latency networking features for edge computing applications. It ends with future directions of these novel technologies and an initial overview of the ELASTIC architecture and components that we are developing to achieve the project objectives. Contractual Date of Delivery 31/08/2025 Actual Date of Delivery 09/09/2025 Deliverable Security Class Public Editor Merlijn Sebrechts (IMEC) Contributors AAL, POLITO, ZEN, LUN, UVC, TUC, ERF, ERS, THS Internal Reviewers Dhouha Ayed (THS) Fionn Mc Inerney (TID)
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 2 - August 31, 2025 The ELASTIC Consortium Part. No. Participant organisation name Participant Short Name Role Country 1 POLYTECHNEIO KRITIS TUC Coordinator EL 2 ERICSSON AB ERS Principal Contractor SE 3 OY L M ERICSSON AB ERF Principal Contractor FI 4 TELEFONICA INNOVACION DIGITAL SL TID Principal Contractor ES 5 THALES SIX GTS FRANCE SAS THS Principal Contractor FR 6 THALES DIS FRANCE SAS THD Principal Contractor FR 7 INTERUNIVERSITAIR MICROELECTRONICA CENTRUM IME Principal Contractor BE 8 ULTRAVIOLET CONSULT DOO UVC Principal Contractor RS 9 AALTO KORKEAKOULUSAATIO SR AAL Principal Contractor FI 10 LUNDS UNIVERSITET LUN Principal Contractor SE 11 ABSTRACT MACHINES SAS AMA Principal Contractor FR 12 PRIVREDNO DRUSTVO ZENTRIX LAB DRUSTVO SA OGRANICENOM ODGOVORNOSCU PANCEVO ZEN Principal Contractor RS 13 POLITECNICO DI TORINO POLITO Principal Contractor IT
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 3 - August 31, 2025 Document Revisions & Quality Assurance Internal Reviewers 1. Dhouha Ayed (THS) 2. Fionn Mc Inerney (TID) Revisions Version Date By Overview 1.0 09/09/2025 TUC, THS Comments and approval from the PC and the STPM 0.9 08/09/2025 TUC Quality check 0.8 02/09/2025 THS, TID Approval from the IRs 0.7 01/09/2025 THS, TID Comments on the 2nd draft 0.6 28/08/2025 IMEC 2nd draft 0.5 16/08/2025 THS, TID, AAL Comments on the 1st draft 0.4 01/08/2025 IMEC First draft 0.3 06/07/2025 AAL, POLITO, ZEN, LUN, UVC, TUC, ERF, ERS, THS Input received 0.2 02/05/2025 AAL, THS Comments on the TOC 0.1 28/04/2025 IMEC TOC Disclaimer The work described in this document has been conducted within the ELASTIC project. This project has received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union’s Horizon Europe research and innovation programme under Grant Agreement No 101139067. This document does not reflect the opinion of the European Union, and the European Union is not responsible for any use that might be made of the information contained therein. This document contains information that is proprietary to the ELASTIC Consortium partners. Neither this document nor the information contained herein shall be used, duplicated, or communicated by any means to any third party, in whole or in parts, except with prior written consent of the ELASTIC Consortium. The quality of this deliverable was improved with the assistance of digital tools; all content was reviewed and approved by the authors.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 4 - August 31, 2025 Table of Contents LIST OF TABLES 6 LIST OF FIGURES 7 LIST OF ABBREVIATIONS 8 EXECUTIVE SUMMARY 11 1 INTRODUCTION 12 1.1 PURPOSE AND SCOPE OF THE DOCUMENT 12 1.2 RELATION TO WORK PACKAGES, DELIVERABLES, AND ACTIVITIES 12 1.3 CONTRIBUTION TO WP1 AND PROJECT OBJECTIVES 12 1.4 STRUCTURE OF THE DOCUMENT 13 2 TECHNOLOGY MOTIVATION 14 2.1 WEBASSEMBLY ON IOT DEVICES 15 2.2 WASM-BASED FEDERATED LEARNING 16 2.3 TEES FOR FEDERATED LEARNING 17 3 WASM & WASI OVERVIEW 18 3.1 INTRODUCTION TO WASM 18 3.2 WEBASSEMBLY SYSTEM INTERFACE (WASI) STANDARDS 18 3.3 WASM RUNTIMES 19 3.4 WASM PERFORMANCE 21 3.4.1 2mm Benchmark 23 3.4.2 2mm Precompiled Benchmark 25 3.4.3 Correlation Benchmark 27 3.4.4 Correlation Precompiled Benchmark 27 3.4.5 Nussinov Benchmark 28 3.4.6 Nussinov Precompiled Benchmark 28 3.4.7 Varying the Size of the Input Dataset 28 3.4.8 Summary 29 3.5 WASM ORCHESTRATION 31 4 WASM & WASI SECURITY 33 4.1 WASM SANDBOX SECURITY 33 4.1.1 Control Flow Integrity 34 4.1.2 Wasm Confidential Computing 35 4.1.2.1 Side-channel Attacks on Memory-Safety 36 4.2 WASM BINARY SECURITY 36 4.2.1 Techniques Designed to Defend Against Malicious Wasm Binaries 37 4.2.2 Techniques Aimed at Protecting Wasm Binaries from External Threats 38 4.2.3 Other Possible Vulnerabilities of Wasm 39 4.2.4 Triggering Unexpected Behaviour 40 4.3 SYSTEM INTERFACE SECURITY 41 4.3.1 Syscall Isolation Through Virtualisation 43 4.3.2 System Call Interception and Validation 43 4.3.3 Separating Computation from System Operations 44 4.3.4 Isolation Through Typed Interface Contracts 45 4.3.5 Filtering of WASI Interfaces 46 4.3.6 Limitations in Usage of Cryptographic Resources 47 4.4 DISTRIBUTED WASM APPLICATION SECURITY 47 4.4.1 Application Identity 47 4.4.2 Migration 48 4.5 ELASTIC WEBASSEMBLY RESEARCH QUESTIONS 49 5 EBPF & XDP 50
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 5 - August 31, 2025 5.1 INTRODUCTION TO EBPF AND XDP 50 5.2 EBPF FOR NETWORKING 51 5.2.1 Cluster Networking 51 5.2.2 Early Packet Drop/Redirection 53 5.2.3 In-kernel Application Offload 54 5.3 EBPF FOR OBSERVABILITY 56 5.3.1 eBPF-based Network Observability Tools 56 5.3.1.1 Qualitative Comparison 58 5.3.2 eBPF-based Performance Profiling Tools 60 5.3.2.1 Qualitative Comparison 61 5.3.3 eBPF-based Security Observability Tools 62 5.3.3.1 Qualitative Comparison 63 5.4 SECURITY ASPECTS OF EBPF 64 5.4.1 eBPF Security Mechanisms 65 5.4.2 Systematic Literature Review Methodology 65 5.4.3 Classification of the Scientific Papers and Contributions 66 5.4.4 Threats, Vulnerabilities, Attack Surfaces, and Exploitation Techniques 67 5.4.5 Mitigation Techniques 69 5.4.6 Security of Hardware Platforms 72 6 ELASTIC DEVELOPMENTS ON EBPF AND WASM SECURITY 76 6.1 ELASTIC DEVELOPMENTS FOR EBPF 76 6.1.1 eBPF Code Security Investigation 76 6.1.1.1 Analysis of eBPF-related CVEs 76 6.1.2 Static eBPF code security analyser 79 6.1.2.1 Motivation and Problem Statement 79 6.1.2.2 Requirements 80 6.1.2.3 State of the Art, Methodology, and Design 81 6.1.2.4 Implementation 83 6.1.2.5 Testing 84 6.1.3 eBPF-based IDS (EO-KPI-9) 85 6.1.3.1 eBPF-based Traffic Capture 86 6.1.3.2 Hardware AI-based IDS solutions 89 6.1.4 eBPF Benchmarking and Performance Evaluation 91 6.1.4.1 Service Mesh Performance Assessment 91 6.1.4.2 eBPF Deployment Performance Evaluation 95 6.2 ELASTIC DEVELOPMENTS ON WEBASSEMBLY SECURITY 96 7 ELASTIC ARCHITECTURE AND COMPONENTS 99 7.1 ARCHITECTURAL SCOPE AND OBJECTIVES 99 7.2 DESIGN PRINCIPLES AND CUTTING-EDGE CAPABILITIES 100 7.2.1 Preparing Integration Through an Abstract Architecture 100 7.2.2 Instantiations Across Work Packages and Demonstrators 101 7.2.3 Enabling Cutting-Edge Capabilities 101 7.3 HIGH-LEVEL ARCHITECTURE OVERVIEW 101 7.4 CORE BUILDING BLOCKS 104 7.4.1 Management & Orchestration 104 7.4.2 Isolation 111 7.4.3 Communication 118 7.4.4 Monitoring & Detection 121 7.4.5 Trust & Access Control 125 7.5 INTEGRATION ACROSS LAYERS AND USE CASES 130 7.6 ROADMAP AND EVOLUTION 131 8 CONCLUSIONS AND NEXT STEPS 133 9 ANNEX - ELASTIC COMPONENT SPECIFICATION FORM 134
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 6 - August 31, 2025 List of Tables Table 1: WebAssembly runtimes for orchestration frameworks in the device-edge-cloud continuum (Legend: AOT: Ahead-of-time; JIT: Just-in-time) ................................................................................ 20 Table 2: Qualitative comparison of WebAssembly runtimes ................................................................ 58 Table 3: Qualitative Comparison of eBPF-based performance profiling tools ..................................... 61 Table 4: qualitative comparison of eBPF-based security observability tools ........................................ 64 Table 5: Classification of output messages in the eBPF verifier code ................................................... 81 Table 6: Federated Learning as a Service (FLaaS) - TID. ................................................................... 104 Table 7: Wasm-operator - IMEC. ........................................................................................................ 105 Table 8: Light-weight Security Orchestrator for Edge Devices - THS. ............................................... 105 Table 9: Federated Learning Toolbox - ZEN. ...................................................................................... 107 Table 10: TEE Software Management Agent - UVC. ......................................................................... 108 Table 11: Reliable enclave migration protocols - AAL. ...................................................................... 109 Table 12: Propeller orchestrator - AMA. ............................................................................................. 110 Table 13: Data protection at-rest at the edge with TEE solution - THS. ............................................. 111 Table 14: WasmHAL-Trust: Automation tooling for confidential computing environments - LUN. 112 Table 15: WASI Security - IMEC. ....................................................................................................... 113 Table 16: Automatic MAC profiles for Wasm runtime containers...................................................... 114 Table 17: WasmHAL Hardware SDK, interfaces, and runtime extensions for securely connecting Wasm applications to hardware across platforms - IMEC .............................................................................. 115 Table 18: Static eBPF code security Analyser - POLITO. .................................................................. 117 Table 19: Static analysis of interaction between Wasm modules - AAL. ........................................... 118 Table 20: Accelerated microservices interconnection - POLITO. ....................................................... 119 Table 21: eBPF distributed state synchronisation - POLITO. ............................................................. 120 Table 22: NETTO - A tool to measure the cost of the Linux network stack in real-time - POLITO. . 121 Table 23: Artificial Intelligence Intrusion Detection/Prevention System - TUC. ............................... 122 Table 24: Mobility attack robust IoT resource allocation model - LUN. ............................................ 123 Table 25: Hardware-based cryptography module - TUC. .................................................................... 124 Table 26: Observability framework for serverless workloads - ERF. ................................................. 125 Table 27: Remote Attestation platform - THD. ................................................................................... 125 Table 28: Key Broker Service - THD. ................................................................................................. 126 Table 29: Multi-platform attestation component - ERF. ...................................................................... 127 Table 30: Light-weight Attribute-based Access Control (ABAC) solution - THS. ............................. 128 Table 31: WASI flexibly-defined capabilities - AAL. ......................................................................... 129 Table 32: ELASTIC Component Specification Template. .................................................................. 134
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 7 - August 31, 2025 List of Figures Figure 1. The average execution time for the three PolyBench/C benchmarks. .................................... 23 Figure 2. The average execution time for the three PolyBench/C benchmarks excluding the WasmEdge runtime’s interpreter mode for better readability. .................................................................................. 23 Figure 3. The CPU and memory usage during the first 30 seconds for the various non-precompiled benchmarks. ........................................................................................................................................... 25 Figure 4. The CPU and memory usage during the first 30 seconds for the various precompiled benchmarks. ........................................................................................................................................... 26 Figure 5. The execution times for the 2mm benchmark using different dataset sizes. .......................... 29 Figure 6. Temporal distribution of eBPF CVE entries .......................................................................... 77 Figure 7. Number of eBPF CVEs affecting the initial release of each Linux kernel minor version ..... 77 Figure 8. Number of eBPF CVEs by category (i.e., module) ................................................................ 78 Figure 9. Analysis of severity and exploitation characteristics of eBPF CVEs ..................................... 79 Figure 10. The two approaches considered for the design of the analyser. ........................................... 82 Figure 11. Examples of output of the Pretty Verifier analyser. ............................................................. 84 Figure 12. Schematic representation of both the traditional and eBPF-powered traffic capture for outbound network traffic. Note how the eBPF capture is able to intercept the message higher in the network stack, thus relaying L4 messages rather than Ethernet frames. ............................................... 87 Figure 13. ELASTIC tool integrating eBPF and AI-IDS for 6G network vulnerability mitigation. ..... 90 Figure 14. Measured throughput (top) and latency (bottom) under multiple service mesh combinations. ................................................................................................................................................................ 94 Figure 15. Comparative latency and throughput measurements of network policies enforcement using eBPF in Calico and Cilium. ................................................................................................................... 95 Figure 16. ELASTIC conceptual architecture. ..................................................................................... 102
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 8 - August 31, 2025 List of Abbreviations ABAC Attribute-Based Access Control ACL Access Control List AI Artificial Intelligence ALU Arithmetic Logic Unit AOT Ahead Of Time AST Abstract Syntax Tree BPF Berkeley Packet Filter BTF BPF Type Format BYOK Bring Your Own Key CBAC Capability-Based Access Control CET Control-flow Enforcement Technology CFI Control Flow Integrity CFG Control Flow Graph CHC Constraint Horn Clauses CNI Container Networking Interface CNN Convolutional Neural Network CPG Code Property Graph CSP Cloud Service Provider CSR Cyber Security and Resilience CVE Common Vulnerabilities and Exposures CVSS Common Vulnerability Scoring System CWE Common Weaknesses Enumeration DLT Distributed Ledger Technology DNAT Destination NATting DOM Document Object Model DRA Data Reconstruction Attack eBPF extended Berkeley Packet Filter EC European Commission ELF Executable and Linkable Format EPF Evil Packet Filter FaaS Function-as-a-Service FL Federated Learning FNWF Formal Methods for WebAssembly Workshop
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 9 - August 31, 2025 FPGA Field Programmable Gate Array GCC Gnu Compiler Collection HSM Hardware Security Module HYOK Hold Your Own Key IBRS Indirect Branch Restricted Speculation IDS Intrusion Detection System IIoT Industrial Internet of Things IoT Internet of Things IT Information Technology JIT Just In Time LKNS Linux Kernel Network Stack LLVM Low Level Virtual Machine LTS Long Term Support MAC Mandatory Access Control MIA Membership Inference Attack MPK Memory Protection Keys MTE Memory Tagging Extensions NAT Network Address Translation NetNS Network NameSpace NIC Network Interface Card NVD National Vulnerability Database OAM Open Application Model OCI Open Container Initiative OT Operational Technology PCI Process Context Identifier PIA Property Inference Attack PKS Protection Key Supervisor PLAS Programming Languages and Analysis for Security PMU Performance Monitoring Unit PoW Proof of Work RAN Radio Access Network RDMA Remote Direct Memory Access ROP Return-Oriented Programming RSS Receive-Side Scaling SEV Secure Encrypted Virtualisation
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 16 - August 31, 2025 kilobytes to execute standard Wasm modules. 9 These runtimes enable real-time responsiveness and efficient use of available resources, especially in latency-sensitive industrial applications. Security through Isolation and Dynamic Updates – Wasm enables execution within a sandbox, shielding the underlying system from potentially harmful code. This is especially important for IoT and IIoT devices that often lack even basic security hardware and are frequently targeted by attackers. In addition, Wasm supports dynamic updates – business logic can be replaced on the fly without modifying the base firmware. This accelerates development cycles and reduces the risk of downtime. Language Flexibility – Wasm supports compilation from various high-level languages such as Rust, C/C++, and Go, allowing teams to reuse existing codebases and apply best practices across diverse ecosystems. This flexibility also facilitates collaboration among interdisciplinary teams without enforcing a single programming language or development paradigm. 2.2 Wasm-based Federated Learning Federated Learning (FL) is a decentralised machine learning paradigm in which multiple devices collaboratively train a shared model while keeping their raw data local 10 . Each participant computes model updates based on its private data and transmits only the learned parameters (e.g., gradients) to an aggregator. This approach enhances privacy, reduces bandwidth usage, and aligns with data sovereignty principles. Beyond vertical-specific use cases, recent research highlights that AI will play a crucial role in managing and optimising 6G networks by enhancing control over radio access networks (RAN), improving resource allocation, increasing energy efficiency, and enabling accurate network traffic prediction 11 . These requirements create the need for new computational execution models that can support secure and efficient processing of AI models in the distributed environment of 6G networks. From that perspective, Wasm offers several key advantages for enabling AI and FL in 6G environments: Modular and Deployable FL Clients - Wasm allows FL logic to be encapsulated into modular, portable execution units that can be directly deployed on IoT or edge devices. Wasm modules can bundle all components of an FL client, including preprocessing, training, and encryption, and be delivered on-demand, without firmware flashing or runtime recompilation. Portability Across Heterogeneous Hardware - Wasm modules are designed to run consistently across diverse CPU architectures and operating systems, following a write-once, run-anywhere principle. 12 This architecture minimises platform-specific dependencies and facilitates unified FL workflows across the highly heterogeneous landscape of 6G edge nodes. Lightweight Execution for Resource-Constrained Devices - Compared to traditional virtual machines (VMs) and containers, Wasm modules offer faster startup times and lower memory and compute overhead. 13 These characteristics make them highly suitable for constrained devices such as wearables, sensors, and industrial microcontrollers - where fast and efficient local execution is critical for FL participation. 9 S. Kakati and M. Brorsson, “WebAssembly beyond the Web: A Review for the Edge-Cloud Continuum,” in Proc. 3rd Int. Conf. Intelligent Technologies (CONIT), Belagavi, India, 2023, doi: 10.1109/CONIT59222.2023.10205816. 10 Y. Liu, X. Yuan, Z. Xiong, J. Kang, X. Wang, and D. Niyato, “Federated Learning for 6G Communications: Challenges, Methods, and Future Directions,” J. Commun. China, Sep. 2020, doi: 10.23919/JCC.2020.09.009. 11 G. Ananthanarayanan, X. Foukas, B. Radunovic, and Y. Zhang, “Distributed AI Platform for the 6G RAN,” arXiv preprint, arXiv:2410.03747, Oct. 2024. [Online]. Available: http://arxiv.org/abs/2410.03747 12 WebAssembly Community Group, “Wasm Component Model – Stage 1 Proposal,” W3C, Nov. 2021. [Online]. Available: https://www.w3.org/2021/11/wasm-stage/ 13 P. Rajendran et al., “A Survey on WebAssembly: Past, Present and Future,” arXiv preprint, arXiv:2404.12621, Apr. 2024. [Online]. Available: https://arxiv.org/abs/2404.12621
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 17 - August 31, 2025 Security, Isolation, and Verifiability - Wasm enforces strict sandbox isolation, preventing access to system resources unless explicitly authorised. This is essential in FL settings, where model code is often deployed dynamically. Additionally, the deterministic behaviour of Wasm ensures verifiable and reproducible execution, a critical requirement for applications in highly regulated sectors such as healthcare, automotive, and finance. 14 2.3 TEEs for Federated Learning Although FL is decentralised and does not require centralised data sharing, models and their gradients can still reveal sensitive information. Attackers can exploit this information through various types of attacks, including Data Reconstruction Attacks (DRA), 15 which aim to reconstruct the original input data by analysing model gradients, Property Inference Attacks (PIA), where specific characteristics of the data are inferred without direct reconstruction, and Membership Inference Attacks (MIA), which attempt to determine whether specific data points were part of the training dataset. 16 These attacks pose a significant privacy risk, as they allow unauthorised access to sensitive information even when the data remains stored locally. One of the proposed solutions is to leverage TEEs, which provide hardware-encrypted secure enclaves for executing FL tasks. TEEs ensure that data and model computations remain confidential, even in potentially untrusted environments. In practice, TEEs can be deployed both on the client side (e.g., IoT devices or smartphones) and on the aggregation side (e.g., a central server or edge gateway). Client-side TEEs ensure that local training and preprocessing are executed in isolated environments, protecting against malware or unauthorised system-level access. Moreover, they make it possible to attest the training environment to detect malicious training attacks. Meanwhile, aggregator-side TEEs can securely aggregate model updates, defend against poisoning attacks, and maintain the integrity of the global model - even in scenarios where the infrastructure is shared or semi-trusted. Moreover, TEEs support remote attestation, a mechanism by which participating devices can cryptographically prove to the orchestrator or other participants that they are running verified and untampered code in a secure enclave. This feature is particularly important in federated systems, where participants are often unknown or loosely coordinated, and trust must be established at runtime. When combined with modular execution environments like Wasm, TEEs become powerful enablers of confidential, auditable, and verifiable FL workflows across highly heterogeneous and dynamic infrastructures, including edge and IoT deployments envisioned in future 6G networks. 14 Z. Wang, F. Wu, F. Yu, Y. Zhou, J. Hu, and G. Min, “Federated Continual Learning for Edge-AI: A Comprehensive Survey,” arXiv preprint, arXiv:2411.13740, Nov. 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2411.13740 15 S. Liu, Z. Wang, Y. Chen, and Q. Lei, “Data Reconstruction Attacks and Defenses: A Systematic Evaluation,” arXiv preprint, arXiv:2402.09478, Mar. 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2402.09478 16 F. Mo, H. Haddadi, K. Katevas, E. Marin, D. Perino, and N. Kourtellis, “PPFL: Privacy-Preserving Federated Learning with Trusted Execution Environments,” in Proc. 19th Annu. Int. Conf. Mobile Syst., Appl., and Services (MobiSys ’21), Jun. 2021, pp. 94–108, doi: 10.1145/3458864.3466628.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 18 - August 31, 2025 3 Wasm & WASI Overview This section gives an overview of the state of the art in WebAssembly and the WebAssembly System Interface. It introduces Wasm, WASI, the different Wasm runtimes, a performance analysis of Wasm runtimes, and a deep-dive into Wasm Orchestration. 3.1 Introduction to Wasm Packaging, sandboxing, and orchestration of compute workloads across devices, edge and cloud or the device-edge-cloud continuum have been studied extensively over the last decade. With the proliferation of cloud-native and the accessibility of cloud-native technologies for more constrained devices, a broader range of possibilities and use cases arise. Cloud-native technologies originated from the flexibility to include multiple workloads in the same node with complete isolation via a VM. Then, containers gained traction because they have smaller footprints, faster boot time, and provide the right levels of isolation while sharing the same kernel. Nowadays, WebAssembly, which was originally designed for executions of workloads for the browser, has become more popular for devices and edge and cloud deployments. It has additional advantages over containers, such as smaller sizes/footprints, faster speeds, and enhanced security. While different technologies might exist, with different advantages and disadvantages, what makes them scale and reach the whole ecosystem are the possibilities for flexible deployments and orchestration mechanisms. For that reason, historically, orchestration frameworks for VMs like OpenStack, or Kubernetes for containers, made the different solutions available to the whole ecosystem. Within the different technologies, there has been a transition period while the VM orchestrator aimed to orchestrate containers, in the same way there are attempts for Kubernetes to provide support to orchestrate Wasm workloads. In the following section, we analyse the different orchestration possibilities for Wasm workloads. We start with a short comparison of the different WebAssembly runtimes, followed by a summary of the orchestration frameworks and techniques proposed in the literature that also act as technical solutions. 3.2 WebAssembly System Interface (WASI) standards WebAssembly modules cannot make system calls directly, for reasons of both isolation and compatibility. However, some Wasm modules require general system functionality, which they access through declared interfaces that are standardised as the WebAssembly System Interface. This allows Wasm to be used outside the browser in general standalone applications. The WASI standard exists in three main iterations: • WASI Preview 1, described in terms of Wasm core modules. Preview 1 provides Clike interfaces written in the witx IDL, and inspired by traditional POSIX APIs 17 . • WASI Preview 2, described with the higher-level wit IDL in terms of the Wasm component model 18 . • WASI Preview 3 will extend WASI Preview 2 with asynchronous interfaces, but is yet to be released. 17 https://github.com/WebAssembly/WASI/tree/main/legacy 18 https://github.com/WebAssembly/WASI/blob/main/wasip2/README.md
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 19 - August 31, 2025 Current development is focused on WASI Preview 2, which currently contains the following APIs and remains open to expansion until the release of WASI Preview 3: • wasi-io, which provides general polling-style stream I/O primitives (replacing this with asynchronous interfaces is a key goal of WASI Preview 3); • wasi-clocks, which provides time-related functionality; • wasi-random, which provides components access to pseudo-random data; • wasi-filesystem, which provides access to the host filesystem; • wasi-sockets, which provides access to the network; • wasi-cli, which provides access to command-line arguments and the terminal; • wasi-http, which provides HTTP client and server functionality, allowing Wasm components to be used as web workers that can be transparently scaled by the host. These interfaces are, in many cases, designed around a capability model, in which access to resources is predicated on the component possessing a handle granting access to each resource; for example, wasi-filesystem 19 allows components to open files in the host filesystem, but they can only do so relative to a directory, with access only allowed within that directory; that is, the component can access only files within that directory, and cannot escape it via symlinks. This behaviour is similar to 20 that of Linux's openat2 syscall when invoked with the RESOLVE_BENEATH option. 21 The component gains access to an initial directory by requesting a list of preopened directory handles from the runtime. Other interfaces take a similar approach to security. The wasi-sockets interface requires the use of a network capability handle to open sockets, 22 but the details of which capabilities are given to a component are runtime-dependent. These interfaces are implemented by a number of runtimes, including: 1. Wasmtime, which implements Previews 1 and 2, with initial asynchronous support 23 ; 2. wasmer, which implements Preview 1 24 ; 3. wasmedge, which implements the Sockets, Crypto, Logging, and Machine Learning proposals 25 . 3.3 Wasm Runtimes WebAssembly has rapidly evolved from its browser origins to become a compelling deployment option across the device-edge-cloud continuum. To execute WebAssembly modules outside browsers, specialised runtimes are required that interpret or compile the Wasm bytecode for execution on the host system. These runtimes implement the WASI to provide standardised access to system resources while maintaining security through capability-based permissions. The choice of runtime significantly impacts performance characteristics, resource utilisation, and deployment flexibility across heterogeneous environments. As organisations increasingly adopt WebAssembly for its portability, security, and efficiency advantages, understanding the trade-offs between different runtime implementations becomes essential for effective orchestration strategies. The comparison captured in Table 1 examines the major WebAssembly runtimes that form the foundation for orchestration frameworks in the device19 https://github.com/WebAssembly/wasi-filesystem 20 https://github.com/WebAssembly/wasi-filesystem/blob/main/path-resolution.md 21 https://man7.org/linux/man-pages/man2/openat2.2.html 22 https://github.com/WebAssembly/wasi-sockets?tab=readme-ov-file 23 https://docs.rs/wasmtime-wasi/34.0.1/wasmtime_wasi/ 24 https://crates.io/crates/wasmer-wasi, v3.1.1 25 https://wasmedge.org/docs/start/wasmedge/extensions/proposals?_highlight=wasi#wasi-proposals, Accessed 2025-06-26
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 20 - August 31, 2025 edge-cloud continuum. The comparison presents a snapshot for each regarding the main implementation language, compilation models (Ahead-of-time, Just-in-time or interpreted), their startup-time and execution speed (for computation overhead), memory footprint (for resource requirements), system interface (WASI, wasm-c-api or custom) and cross-architecture support - for interoperability. Additionally, their key strengths and main use cases are highlighted and can be used for a quick matching to new use cases and scenarios. Table 1: WebAssembly runtimes for orchestration frameworks in the device-edge-cloud continuum (Legend: AOT: Ahead-of-time; JIT: Just-in-time) wasmtime26,27 wasmer28 wasmedge WAMR (WebAssembly Micro Runtime)29,30 WAVM (WebAssembly Virtual Machine)31,32 Wasm3 33, 34 Origin Bytecode Alliance Wasmer, Inc. CNCF Bytecode Alliance - - Implementatio n language Rust Rust, C++ C++ C C++, Python C Compilation models JIT (Cranelift), AOT JIT (LLVM, Cranelift, single pass), AOT AOT, Interpreted Interpreted, AOT, JIT (LLVM, Fast JIT, Multi-tier JIT) JIT Interpreted Startup times Excellent (30150 ms typical) Good Very Good Varies by mode (AOT: excellent, JIT: slow) Moderate Good Execution Speed Very good Excellent with LLVM Good Varies by mode (AOT: near-native, Interpreter: slower) Very good Moderate Memory Footprint Moderate (~40MB) Moderate Small Very small (AOT: ~200KB, Interpreter: 200KB, JIT: ~40MB) Large Very small System Interface WASI, wasm-capi WASI, wasm-c-api WASI wasm-c-api WASI WASI, custom CrossArchitecture Support Excellent Good Good Excellent (including embedded devices) Limited (x8664 focus) Good Key Strengths Fast startup, security focus, standards compliance Multiple backends, package manager (WAPM), embeddability Cloud-native focus, Kubernetes integration, AI extensions Resource efficiency, modularity, embedded systems Performance Portability, small footprint Use cases Serverless functions, security-critical applications Long-running services, production environments Cloud-native applications, edge computing IoT devices, resourceconstrained environments Performancecritical applications Embedded systems, resourceconstrained devices 26 "Wasmtime: A small and efficient runtime for WebAssembly & WASI." https://github.com/bytecodealliance/wasmtime, accessed 2025-05-15 27 The Bytecode Alliance regularly publishes performance benchmarks comparing Wasmtime with other runtimes: https://bytecodealliance.org/articles/wasmtime-10-performance, accessed 2025-05-15 28 Wasmer, Inc. "Wasmer: The Universal WebAssembly Runtime." https://github.com/wasmerio/wasmer, accessed 2025-0515 29 Bytecode Alliance. "WebAssembly Micro Runtime (WAMR)." https://github.com/bytecodealliance/wasm-micro-runtime, accessed 2025-05-15 30 Analysis of WAMR's performance characteristics on resource-constrained devices: https://www.intel.com/content/www/us/en/developer/articles/technical/webassembly-on-iot-devices.html, accessed 2025-0515 31 Wavix. "WAVM: WebAssembly Virtual Machine." https://github.com/WAVM/WAVM 32 "A Comprehensive Analysis of WebAssembly Runtime Performance" by Lin Clark and Till Schneidereit https://arxiv.org/abs/2012.01946, accessed 2025-05-15 33 "Wasm3: The fastest WebAssembly interpreter." https://github.com/wasm3/wasm3 34 Performance metrics for the ultra-portable Wasm3 interpreter: https://github.com/wasm3/wasm3#performance, accessed 2025-05-15
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 21 - August 31, 2025 Kakati and Brorsson 35 present a comprehensive cross-architecture evaluation of WebAssembly in the cloud-edge continuum, conducting the first-ever analysis across four diverse platforms: two server-class architectures (X86_64 and ARM64) and two embedded boards (Nvidia Jetson Nano with ARM64 and StarFive VisionFive2 with RISCV64), focusing on Wasmtime and WAMR. Their findings demonstrate that WebAssembly achieves near-native execution speed for many benchmarks, with more than 50% of tested benchmarks running within a factor of 2x the native execution time on Wasmtime, while WebAssembly modules are significantly smaller than corresponding native executables. The study reveals Wasmtime consistently delivers optimal startup times (30-150ms) across all architectures, with some X86_64 applications achieving remarkably low startup times of 1-2ms, whereas WAMR with LLVM JIT exhibits startup times approximately 10 times longer, though this can be mitigated using WAMR's fast JIT mode. Ahead-of-time compilation brings performance even closer to native execution with very low startup times (typically less than 10μs), though at the cost of losing architecture independence. The research highlights that embedded platforms, particularly RISCV64, show significantly slower performance compared to server architectures due to differences in processor capabilities. The ARM Cortex-A57's out-of-order pipeline design provides advantages over the Vision5’s dual-issue, in-order execution pipeline. These results ultimately demonstrate WebAssembly's potential as a cross-platform solution while identifying areas for future optimisation in resource-constrained edge environments. This study, however, only focuses on the runtimes of the ByteCode Alliance, specifically WAMR and Wasmtime. As such, a more thorough analysis is needed of the most prominent WebAssembly runtimes. As part of ELASTIC, we are performing a more thorough analysis of the most prominent runtimes, as shown in the next section. 3.4 Wasm Performance As the existing literature about WebAssembly runtime performance does not contain a recent study comparing the performance of the most popular WebAssembly runtimes, ELASTIC performed a thorough analysis of key performance metrics of the most popular WebAssembly runtimes: WAMR, Wasmtime, Wasmedge and Wasmer. This analysis also includes all available runtime modes to get a more holistic understanding of performance characteristics. This was achieved using the synthetic benchmarking suite named PolyBench/C 36 (version 4.2.1 beta). This benchmarking suite was selected due to its simplicity, popularity, portability, and suitability for runtime testing. It consists of various computational benchmarks written in C, each with its respective header and source files. Since these computational benchmarks rely exclusively on the PolyBench benchmarking framework and have no complex dependencies, and since the entire suite is written in C, compilation to WebAssembly is straightforward using wasi-sdk 37 . For this performance study, three representative benchmarks have been selected from this suite: 2mm, correlation, and Nussinov. After compiling the three selected benchmarks from PolyBench/C to WebAssembly, the runtime-specific toolchains were used to precompile (i.e., AOT compile) the Wasm binaries to optimised binary code for x86 that can be used by the respective runtime to execute the benchmark. The non-precompiled (regular) Wasm binaries, as well as the precompiled binaries, 35 Kakati, Sangeeta, and Mats Brorsson. "A Cross-Architecture Evaluation of WebAssembly in the Cloud-Edge Continuum." 2024 IEEE 24th International Symposium on Cluster, Cloud and Internet Computing (CCGrid). IEEE, 2024. 36 Ohio State University. "PolyBenchC-4.2.1." https://github.com/MatthiasJReisinger/PolyBenchC-4.2.1 , accessed 2025-0515 37 WebAssembly "WASI-enabled WebAssembly C/C++ toolchain." https://github.com/WebAssembly/wasi-sdk , accessed 202508-20
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 22 - August 31, 2025 were executed 25 times in a random order in each runtime using the runtime’s default options. Since some runtimes are highly customisable, e.g., different Just-in-time compilation backends, and certain options might affect performance, each benchmark was also executed 25 times with different runtime options. Figure 1 presents the execution time results for the three selected PolyBench/C benchmarks in all the tested runtimes, the results are shown with a 95% confidence interval. The tested runtimes and their options are described below. • Native: native x86-64 ELF binary. • WAMR AOT: WAMR running the AOT precompiled binary. • WAMR Classic Interpreter: WAMR running the regular Wasm binary using WAMR’s classic interpreter. • WAMR Fast Interpreter: WAMR running the regular Wasm binary using WAMR’s fast interpreter. This is the default WAMR mode. • WAMR Fast JIT: WAMR running the regular Wasm binary using WAMR’s Fast Justin-time (JIT) compiler. • WAMR LLVM Eager JIT: WAMR running the regular Wasm binary using LLVM ORC (On-Request-Compilation) JIT compiler in eager mode. Eager mode will compile all JIT functions before running them. • WAMR LLVM Lazy JIT: WAMR running the regular Wasm binary using LLVM ORC JIT compiler in lazy mode. Lazy mode will prioritise startup time and compile the JIT functions that were not already compiled at startup only when they are first called. • WAMR Multi JIT: WAMR running the regular Wasm binary using multi-tier JIT compiler. The multi-tier JIT is a two level JIT tier-up engine, which launches the Fast JIT to run the Wasm module as soon as possible and creates backend threads to compile the LLVM JIT functions at the same time. Once the LLVM JIT functions are compiled the runtime will gradually switch the execution to the LLVM JIT code to gain the best performance. • WasmEdge AOT: WasmEdge running the AOT precompiled binary. • WasmEdge Interpreter: WasmEdge running the regular Wasm binary in interpreter mode. • WasmEdge JIT: WasmEdge running the regular Wasm binary in JIT mode. WasmEdge’s JIT runs eagerly by calling the WasmEdge AOT compiler before execution. • Wasmer Cranelift AOT: Wasmer running the AOT precompiled binary that was compiled by Cranelift. • Wasmer LLVM AOT: Wasmer running the AOT precompiled binary that was compiled by LLVM. • Wasmer Cranelift JIT: Wasmer running the regular Wasm binary in JIT mode using Cranelift as JIT compiler. • Wasmer LLVM JIT: Wasmer running the regular Wasm binary in JIT mode using LLVM as JIT compiler. • Wasmtime AOT: Wasmtime running the AOT precompiled binary. • Wasmtime JIT: Wasmtime running the regular Wasm binary in JIT mode.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 23 - August 31, 2025 Figure 1. The average execution time for the three PolyBench/C benchmarks. It is clear from Figure 1 that WasmEdge’s interpreter is extremely slow compared to all the other runtimes. To be able to better compare the other runtimes, Figure 2 excludes WasmEdge Interpreter mode from the results. These results indicate that all interpreter modes are significantly slower than JIT and AOT modes. Figure 2. The average execution time for the three PolyBench/C benchmarks excluding the WasmEdge runtime’s interpreter mode for better readability. 3.4.1 2mm Benchmark The execution time for the 2mm benchmark exhibited minimal variance across all experimental runs. Both Wasmtime and Wasmer achieved execution times comparable to native execution, slowing down slightly compared to native. In contrast, WasmEdge showed significantly slower performance in interpreted mode, with an execution time of 194.65 seconds, reflecting its limitations. This aligns with expectations, as WasmEdge’s interpreter is primarily designed for verification purposes, with precompilation recommended for optimal performance. It is noteworthy that the WAMR AOT mode outperforms native execution. These results are attributed to a combination of code optimisations performed by WAMR, such as the use of more and advanced SIMD vectorisation instructions and the use of a simple built-in heap memory management system, allowing it to achieve faster execution. More specifically, the following optimisations were observed. • WAMR is much more able to vectorise the 2mm benchmark code than the native compilers and the other runtimes, despite explicitly enabling SIMD vectorisation in all runtimes and compilers. • The native binary uses malloc for memory allocation, which has shown significant overhead compared to a more efficient memory allocator like jemalloc. WAMR on the other hand uses a simpler memory management system, and the runtime may already
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 24 - August 31, 2025 have allocated enough memory at startup reducing its need to perform repeated host system calls to enlarge the heap allocation. • This benchmark compares 32-bit WebAssembly with 64-bit native code. This also contributes to the performance improvements as 32-bit code still has a slight performance advantage compared to 64-bit code, even on modern intel CPUs. In terms of CPU usage, most runtimes showed relatively stable behaviour. However, WAMR’s multi-tier JIT exhibited a slight increase in CPU usage, probably due to the transition from a fast JIT to LLVM JIT early on in the execution, which causes a temporary CPU spike, as shown in Figure 3a. Regarding memory usage, native code is the most efficient, as expected, since it bypasses the overhead of running within an additional environment. Both Wasmtime and WAMR interpreters also performed well, trading off speed for lower memory consumption. On the other hand, JIT modes, such as WAMR’s LLVM JIT and multi-tier JIT, consumed considerably more memory (Figure 3b). This reflects a typical space-time trade-off, where faster execution is achieved at the cost of increased memory usage.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 25 - August 31, 2025 Figure 3. The CPU and memory usage during the first 30 seconds for the various non-precompiled benchmarks. 3.4.2 2mm Precompiled Benchmark All runtimes running an AOT binary have comparable execution times to native execution, with WAMR slightly improving the native execution time, and the other runtimes being slightly slower. Although the performance difference between the AOT runtime modes and native execution is not statistically significant, the results demonstrate the potential efficiency gains from precompiling Wasm binaries. In contrast to the variability observed in interpreter and JIT modes, the CPU usage in AOT mode is identical across all runtimes and equivalent to native execution, as shown in Figure 4a.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 32 - August 31, 2025 modules to be loaded on a necessary basis. Future work includes dynamic orchestration and self-organisation while taking into account dynamic linking. 44 Based on the paper by Vaño et al. 45 , the authors present a comprehensive deployment review of cloud-native workload orchestration technologies for edge computing environments. They analyse the evolution from traditional container virtualisation to edge-adapted solutions, examining lightweight container runtimes (crun and youki), purpose-built operating systems (EVE-OS and BalenaOS), and Kubernetes adaptations (K3s, MicroK8s, and KubeEdge). The paper identifies WebAssembly as a particularly promising technology for edge environments due to its smaller footprint, faster startup times, and enhanced security compared to containers. The authors highlight how Wasm modules can be integrated with container technologies through runtimes like WasmEdge, and orchestrated using Kubernetes extensions such as Krustlet. They conclude that while containers will remain important, WebAssembly represents a significant advancement that addresses many edge computing constraints, with the joint orchestration of heterogeneous workloads (containers alongside Wasm modules) emerging as a key trend for the near future. In the ELASTIC project, Wasm Orchestration is investigated more thoroughly in WP2, and D2.1 46 shows our initial developments in addressing some of the fundamental issues in WebAssembly Orchestration. 44 Mäkitalo, N., et al. "Bringing webassembly up to speed with dynamic linking." Proceedings of the 36th Annual ACM Symposium on Applied Computing. 2021. 45 Vaño, R.; Lacalle, I.; Sowiński, P.; S-Julián, R.; Palau, C.E. Cloud-Native Workload Orchestration at the Edge: A Deployment Review and Future Directions. Sensors 2023, 23, 2215. https://doi.org/10.3390/s23042215 46 ELASTIC Project, Lightweight and Robust Orchestrating Mechanisms – Initial Version (Deliverable D2.1), Zenodo, 2025. doi: 10.5281/zenodo.15100798
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 33 - August 31, 2025 4 Wasm & WASI Security This section provides an analysis of the security features of Wasm and WASI and explains the research directions of the ELASTIC project to improve Wasm security. It concludes with a summary of the security-related research questions that ELASTIC is targeting. The preliminary results of this research, however, are reported in Section 6. There are many aspects to Wasm security. The first aspect is the Wasm Sandbox that uses fault isolation, control-flow integrity and memory sandboxing. These mechanisms aim to prevent low-level memory vulnerabilities while enabling high-performance execution of untrusted code. While this was originally designed to run untrusted code in the browser, it is equally valuable and useful in IoT and edge environments. Moreover, privacy-centric data sharing introduces new attack vectors and requires new sandboxing features such as confidential computing. Section 4.1 goes into greater detail about the security of the WebAssembly sandbox. Even when code is completely sandboxed, however, there are still security considerations for the Wasm binaries themselves. For example, untrusted workloads could “steal” CPU time to mine cryptocurrencies, or external actors could try to exploit vulnerabilities in Wasm applications in order to steal sensitive data these applications have access to. Section 4.2 investigates how to detect malicious applications and protect legitimate applications. Fully isolating Wasm applications is not always desirable, especially in 6G networks where services need to collaborate or access hardware to perform network functions. As such, Wasm has a system interface that allows Wasm applications to communicate with entities outside of the sandbox. Section 4.3 details how this sandbox works and the security advantages and implications of the WebAssembly System Interface. Running Wasm applications in highly distributed environments like 6G networks introduces new opportunities but also new attack vectors. Not only should individual Wasm applications be secure, but their interaction and the emergent behaviour also needs to be secure. Section 4.4 investigates the security of distributed Wasm application constellations. Finally, Section 4.5 summarises the open challenges identified in this section into a number of streamlined research questions that ELASTIC is working on to address. 4.1 Wasm Sandbox Security WebAssembly is inherently designed around isolation-based security and is intended to provide three core security features: 1. Sandboxed environment: Wasm binaries run in a sandboxed environment, and they are isolated from the host system. Wasm binaries cannot access external resources unless the default has been changed and an access is explicitly defined and permitted through approved APIs. For example, in browsers, Wasm modules interact with the Document Object Model (DOM) only via JavaScript APIs, and therefore, they are restricted by the same-origin policy. Similarly, standalone Wasm runtimes with OS support require designated APIs to access files and/or network sockets. 2. Linear memory: By default, a Wasm module is instantiated with a defined linear memory, which provides the initial allocation required for its execution. Internally, a JavaScript engine or system runtime sets up a managed memory buffer (such as an ArrayBuffer in JavaScript). As a result, the Wasm module accesses memory indirectly through this buffer. This design ensures that the module’s linear memory is limited to a
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 34 - August 31, 2025 controlled and allocated space. Therefore, a Wasm module is restricted to read and write only within its allocated space. 3. Control-flow integrity: At runtime, Wasm enforces control-flow integrity (CFI) for direct/indirect function calls and for returns. To support this, the compiler constructs a control-flow graph (CFG) during the compilation process. The utilisation of a CFG ensures that any execution path deviating from the CFG is rejected. For indirect function calls, Wasm protects the execution by utilising function indices. These indices and their type metadata are mapped in a function table. Each call is then validated against this type information. Return operations are protected through a secure call stack. This prevents unauthorised control flow manipulations. However, Wasm suffers from several security flaws and vulnerabilities that have negatively affected its widespread utilisation in cloud computing. For example, the near-native execution speed of Wasm applications is appealing to cybercriminals, leading to the emergence of resource-stealing malware (e.g., cryptominers) that are built on Wasm. Without effective defence mechanisms, these threats can cause significant financial damage to cloud users. Additionally, Wasm’s support for type-unsafe languages like C and C++ makes its binaries particularly vulnerable to a broad range of memory-related bugs (e.g., buffer overflows 47 ). Mitigating these limitations is explained in detail in Section 4.2. 4.1.1 Control Flow Integrity WebAssembly has Control Flow Integrity baked-in by default in its specification. This CFI allows preventing attacks that would manipulate the control flow of the Wasm program and leverage code reuse to execute harmful code. For direct function calls, the identifier of the function is hardcoded into the code, which means it is impossible to call another function other than the one intended thanks to the Wasm code memory isolation. However, in order to retain compatibility with C/C++ code using function pointers, the specification introduces a call_indirect instruction which takes as parameter the index of the function to call, that is provided through the (potentially user-controlled) linear memory. The Wasm specification does not allow calling arbitrary addresses, but only functions in a table that match the expected signature, with the same input (parameters) and output (result) types. However, if multiple functions in the table have the same signature, then an attacker capable of modifying the linear memory could choose which function to call, thus defeating the CFI. This attack can be potentially powerful as there are only four basic Wasm types (i32, i64, f32, f64) that can represent a lot of different things in memory. For example, in Wasm 32 bits, an i32 can represent a memory pointer, a signed or unsigned integer, or a boolean. Without context from the source code, it is impossible for the Wasm CFI to distinguish between these situations, making the Wasm CFI very coarse-grained. For these reasons, the Wasm CFI is weaker than CFI implemented at compile time like LLVM's CFI. Compile time CFI allows for fine-grained signature matches, relying on the rich types provided by programming languages. Furthermore, they allow for other features such as injecting additional instructions or metadata into the final binary, strengthening the CFI in ways that are impossible for the Wasm CFI. For these reasons, developers targeting Wasm must remember that the Wasm CFI is a good measure that is better than a lack of CFI, but it is not as strong as compile-time CFI and not strong enough to protect against advanced attacks. 47 D. Lehmann, J. Kinder, and M. Pradel, “Everything old is new again: Binary security of webassembly,” in 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 217–234.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 35 - August 31, 2025 4.1.2 Wasm Confidential Computing The traditional Wasm sandbox is built to contain applications so that they cannot access resources outside of the sandbox. This does not protect against attacks from the host OS or physical attacks, however. For this reason, the Wasm sandbox is increasingly supplemented with a confidential computing layer. Technologies such as hardware-backed TEEs ensure data and workload confidentiality and integrity, while the Wasm sandbox ensures workload isolation. Within such a combined architecture, the Wasm runtime is a core component that executes inside the TEE's secure boundary. Positioned above a minimal Linux kernel acting as a hardware abstraction layer, the Wasm runtime ensures platform portability while maintaining isolation from the untrusted host system. The runtime is responsible for managing module execution, memory, and system interface calls, with all Wasm linear memory confined within the TEE's protected space. This isolation is further extended by embedding the WASI inside the TEE, and translating WASI calls to secure TEE APIs. This enables a secure system call abstractions that do not expose sensitive data or control flow to the untrusted host. Environments like Enarx exemplify this model by executing both the Wasm runtime and the WASI implementation entirely within the TEE. All interactions between the Wasm module and the external host, such as file I/O or networking, are mediated by a trusted layer—sometimes a microkernel or shim—that encrypts and sanitises data before it crosses the secure boundary. This architecture ensures that the untrusted host cannot access module memory or internal execution state, thereby upholding confidentiality and integrity guarantees. Higher-level protocols like waPC (WebAssembly Procedure Calls) enhance this model by standardising structured argument passing via memory pointers and lengths within the Wasm linear memory, thereby supporting efficient and secure inter-module communication without relying on traditional syscall-based mechanisms. To further harden Wasm’s security model—especially in multi-tenant or embedded scenarios— recent research has explored novel runtime and hardware-assisted techniques. WASMBOX 48 introduces a lightweight runtime optimised for embedded systems, offering secure multitenancy through sandboxed execution, enhanced resource utilisation, and a patched WASI interface for safe system calls. Additionally, it integrates runtime anomaly detection mechanisms operating within TEEs, enabling real-time protection against unauthorised resource access. Hardware-assisted isolation has also shown promise. Cage 49 utilises Intel Memory Protection Keys (MPK) to enforce in-process memory isolation for Wasm modules with minimal overhead, enabling efficient context switching and improved performance. Similarly, Swivel 50 implements a hybrid compiler framework leveraging CPU features like Speculative Store Bypass Disable (SSBD) and Indirect Branch Restricted Speculation (IBRS) to mitigate Spectrestyle side-channel vulnerabilities, reducing the need for costly software-only mitigations. Okapi 51 pushes this concept further by introducing dedicated hardware structures for 48 Coppolino, L., et al. (2024). WASMBOX: A lightweight Wasm-based runtime for trustworthy multi-tenant embedded systems. IEEE Trans. Emerg. Topics Comput.. https://doi.org/10.1109/TETC.2024.3409817. 49 Fink, M., et al. "Cage: Hardware-accelerated safe webassembly." Proceedings of the 23rd ACM/IEEE International Symposium on Code Generation and Optimization. 2025. 50 Narayan, S., et al. "Swivel: Hardening WebAssembly against spectre." 30th USENIX Security Symposium (USENIX Security 21). 2021. 51 Schmitz, P., et al. "Okapi: Efficiently Safeguarding Speculative Data Accesses in Sandboxed Environments." arXiv preprint arXiv:2312.08156 (2023).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 36 - August 31, 2025 speculative execution control, using metadata tagging and commit/abort logic to ensure secure memory access during speculation. In a more radical departure from conventional software execution models, Kim et al. 52 , 53 propose an Field Programmable Gate Array (FPGA)-accelerated Wasm runtime connected via Serial Peripheral Interface (SPI) to a Raspberry Pi. By offloading Wasm bytecode interpretation to reconfigurable logic, their architecture achieves up to 142× performance gains compared to standard software execution on the same platform, demonstrating the potential of hardware specialisation in edge computing contexts. In conclusion, hardware-assisted mechanisms offer a compelling path forward for enhancing the security and efficiency of WebAssembly. By leveraging emerging hardware features such as speculative execution controls, memory tagging, and reconfigurable acceleration, future work will continue to expand the boundaries of secure and high-performance Wasm execution across a broad spectrum of platforms, particularly in edge and embedded contexts. 4.1.2.1 Side-channel Attacks on Memory-Safety Cloud computing opens the possibility of companies accessing high computational power without requiring the need to invest large sums of money into the necessary hardware and setup. This introduces a new security risk, however, as data needs to be stored at the cloud service providers (CSPs), which demands the trust of the customer in the CSP, limiting the potential use-case of the technology. As a means to protect the customers, vendors like AMD and Intel have both released TEEs, which aim to add confidentiality to the customer’s data through encryption. Intel released SGX, which is an enclave that encrypts the data related to one application. AMD later released Secure Encrypted Virtualisation (SEV), which encrypts the entire VM used by the guest. This encryption is supposed to protect the guest user from a malicious hypervisor. However, since the release of both SGX and SEV, side channel attacks have continuously broken this confidentiality in multiple studies. Puddu et al. 54 showed that executing code with Wasm increased the side channel leakage. This was exploited, and confidential code was extracted by being executed in SGX through fingerprinting the Wasm instructions. In the paper, they only applied the attack against SGX. In ELASTIC, we are attempting to perform a similar attack in AMD SEV by utilising the framework SEVstep. We have been able to extract the side channels, such as the latency of machine code with single-instruction granularity, and are attempting to extract other side channels, such as power consumption and read and write to memory, to perform the attack. 4.2 Wasm Binary Security Even with the strong sandbox enforcement of Wasm runtimes, Wasm apps are still susceptible to vulnerabilities. For example, Wasm apps compiled from memory-unsafe like C and C++ languages might still contain memory vulnerabilities. Secondly, the sandbox cannot prevent applications from performing undesirable behaviour inside of it. For example, Cryptojackers could still maliciously use the CPU time allocated to that app for mining cryptocurrencies. 52 Kim J. et al. (2024). Accelerating embedded WebAssembly based on FPGA. Proc. 21st Int. SoC Design Conf. (ISOCC), 187–188, 2024. 53 Kim J. et al. (2024), "Hardware-Based WebAssembly Accelerator for Embedded System," Electronics, vol. 13, no. 20, Art. no. 3979, 2024. 54 Puddu, Ivan, Moritz Schneider, Daniele Lain, Stefano Boschetto, and Srdjan Čapkun. "On (the lack of) code confidentiality in trusted execution environments." In 2024 IEEE Symposium on Security and Privacy (SP), pp. 4125-4142. IEEE, 2024.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 37 - August 31, 2025 Kim et al. 55 present a comprehensive survey of cutting-edge security techniques for Wasm binaries. Specifically, they categorised existing research based on their methodological approach and the security challenges they aim to address. Based on their categorisation, prior work on Wasm security falls into two main categories: (1) techniques to detect malicious Wasm binaries such as cryptojacking malware, and (2) techniques to detect and mitigate vulnerabilities such as buffer overflows in legitimate binaries. These techniques generally fall into three methodological categories. • Static analysis involves examining the binary code or source code of Wasm modules without executing them. This approach aims to detect vulnerabilities, enforce security policies, or ensure compliance before runtime. • Dynamic analysis observes the runtime behaviour of Wasm binaries, including changes in input/output, environment variables, and execution states. This approach is used to detect suspicious behaviour and runtime-based vulnerabilities. • Hybrid approaches combine both static and dynamic analyses to leverage the strengths of each method. The hybrid approach often results in more robust security assessments. 4.2.1 Techniques Designed to Defend Against Malicious Wasm Binaries Protecting the system against malicious Wasm binaries can be done by the following techniques. • Static Analysis-Based Methods. Two of the noteworthy techniques of these methods are as follows. MINOS 56 detects Wasm-based cryptojacking by converting Wasm binaries into grayscale images for classification via a Convolutional Neural Network (CNN). MinerRay 57 analyses CFGs derived from Wasm binaries to trace cryptographic algorithms that are typically found in cryptojacking. • Dynamic Analysis-Based Methods. Here, we review some of the noteworthy techniques of these methods. RAPID 58 detects attacks by monitoring runtime behaviours. CoinSpy 59 detects Proof of Work (PoW)-based cryptojacking by utilising CNNs for classification. MineThrottle 60 identifies attacks through instruction frequency anomalies. Outguard 61 inspects JavaScript runtime and rendering engine behaviours, focusing on features like WebSockets, hash functions, and Wasm event patterns. • Hybrid Analysis-Based Method. To combine the benefits of both approaches, SEISMIC 62 adopts a hybrid model. It builds abstract syntax trees and inserts global variables to track instruction execution during runtime. SEISMIC achieves a high accuracy even with minimal feature sets. 55 Kim, M., Jang, H., & Shin, Y. (2022, July). Avengers, Assemble! survey of WebAssembly security solutions. In 2022 IEEE 15th International Conference on Cloud Computing (CLOUD) (pp. 543-553). IEEE. doi: 10.1109/CLOUD55607.2022.00077. 56 F. Naseem, A. Aris, L. Babun, E. Tekiner, and S. Uluagac, “Minos: A lightweight real-time cryptojacking detection system,” in Annual Network and Distributed System Security Symposium (NDSS), 2021. 57 A. Romano, Y. Zheng, and W. Wang, “Minerray: Semantics-aware analysis for ever-evolving cryptojacking detection,” in 2020 35th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2020, pp. 1129–1140. 58 J. D. P. Rodriguez and J. Posegga, “Rapid: Resource and api-based detection against in-browser miners,” in Proceedings of the 34th Annual Computer Security Applications Conference. ACM, 2018. 59 C. Kelton, A. Balasubramanian, R. Raghavendra, and M. Srivatsa, “Browser-based deep behavioral detection of web cryptomining with coinspy,” in Workshop on Measurements, Attacks, and Defenses for the Web (MADWeb). NDSS, 2020. 60 W. Bian, W. Meng, and M. Zhang, “Minethrottle: Defending against Wasm in-browser cryptojacking,” in Proceedings of The Web Conference 2020. ACM, 2020. 61 A. Kharraz, Z. Ma, P. Murley, C. Lever, J. Mason, A. Miller, N. Borisov, M. Antonakakis, and M. Bailey, “Outguard: Detecting in-browser covert cryptocurrency mining in the wild,” in The World Wide Web Conference, 2019, pp. 840–852. 62 W. Wang, B. Ferrell, X. Xu, K. W. Hamlen, and S. Hao, “Seismic: Secure in-lined script monitors for interrupting cryptojacks,” vol. 11099 LNCS. Springer Verlag, 2018, pp. 122–142.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 38 - August 31, 2025 4.2.2 Techniques Aimed at Protecting Wasm Binaries from External Threats Recent work has focused on improving Wasm security through (a) vulnerability analysis and (b) protection techniques. This section summarises key efforts on improving Wasm binary security. a) Vulnerability Analysis Wasm supports multiple languages, including unsafe ones like C/C++, which may introduce memory issues such as buffer overflows. Thus, vulnerability analyses of Wasm binaries are crucial. In what follows, we present some of the noteworthy technologies in each of the static, dynamic, and hybrid methods. • Static Analysis-Based Methods. Wasmati 63 builds a code property graph (CPG) to monitor control flow, data dependencies, and execution order. The aim is to detect C/C++-based vulnerabilities and Wasm–JavaScript interface flaws. Wassail 64 analyses isolated functions in Wasm by summarising their configurations. It aims to support static analyses, such as code querying and data flow analysis. • Dynamic Analysis-Based Methods. Fuzzm 65 introduced greybox fuzzing and canarybased protection to uncover memory corruption vulnerabilities. WAFL 66 uses VM snapshots for efficient resets, and is applicable inside and outside the browsers. • Hybrid Analysis-Based Method. Wasabi 67 modifies Wasm bytecode to instrument binaries and tracks instruction-level behaviour during runtime. b) Attack Protection Techniques The following solutions aim to protect against emerging attacks on Wasm: • Constant-Time Programming: To defend against side-channel attacks, several methods, such as Vivienne 68 and CT-Wasm, 69 are used to ensure constant-time execution. These methods restrict secret-dependent control flow. • Microarchitectural Attack Protection: Swivel 70 is a compiler-driven defence mechanism designed to mitigate microarchitectural attacks that target conditional branch predictors, branch target buffers, and return stack buffers. It consists of two distinct implementations: Swivel Software-Based Fault Isolation (Swivel-SFI) and Swivel Control-Flow Enforcement Technology (Swivel-CET). Lurking Eyes 71 analyses HTML-embedded JavaScript for cache side-channel attacks. 63 P. D. R. Lopes, “Discovering vulnerabilities in webassembly with code property graphs.” Tecnico Lisboa, 2021. 64 Q. Stievenart and C. De Roover, “Compositional information flow analysis for Webassembly programs,” in 2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 2020, pp. 13–24. 65 D. Lehmann, M. T. Torp, and M. Pradel, “Fuzzm: Finding memory bugs through binary-only instrumentation and fuzzing of webassembly,” arXiv preprint arXiv:2110.15433, 2021. 66 K. Haßler and D. Maier, “Wafl: Binary-only webassembly fuzzing with fast snapshots,” in Reversing and Offensive-oriented Trends Symposium, 2021, pp. 23–30. 67 D. Lehmann and M. Pradel, “Wasabi: A framework for dynamically analyzing webassembly,” in Proceedings of the TwentyFourth International Conference on Architectural Support for Programming Languages and Operating Systems, 2019, pp. 1045–1058. 68 R. M. Tsoupidi, M. Balliu, and B. Baudry, “Vivienne: Relational verification of cryptographic implementations in Webassembly,” in 2021 IEEE Secure Development Conference (SecDev). IEEE, 2021, pp. 94– 102. 69 C. Watt, J. Renner, N. Popescu, S. Cauligi, and D. Stefan, “Ct-wasm: typedriven secure cryptography for the web ecosystem,” Proceedings of the ACM on Programming Languages, vol. 3, no. POPL, pp. 1–29, 2019. 70 S. Narayan, C. Disselkoen, D. Moghimi, S. Cauligi, E. Johnson, Z. Gang, A. Vahldiek-Oberwagner, R. Sahita, H. Shacham, D. Tullsen et al., “Swivel: Hardening Webassembly against spectre,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 1433–1450. 71 M. E. Mazaheri, F. Taheri, and S. B. Sarmadi, “Lurking eyes: A method to detect side-channel attacks on javascript and webassembly,” in 2020 17th International ISC Conference on Information Security and Cryptology (ISCISC). IEEE, 2020, pp. 1–6.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 39 - August 31, 2025 • Software Attack Defence: MS-Wasm 72 protects Wasm memory with hardware-level isolation. SELWasm 73 encrypts Wasm code to secure execution. VeriWasm 74 performs static verification using CFGs to ensure memory isolation and safety at compile time. Specifically, according to the compiled Wasm binary, VeriWasm generates a CFG that is used to examine the safety features of the functions within a module. 4.2.3 Other Possible Vulnerabilities of Wasm McFadden et al. 75 discuss the following other possible vulnerabilities of Wasm: • Integer Overflows/Underflows: In WebAssembly, there are four value types, including integers (i32, i64) and floating points (f32, f64), which behave differently from JavaScript numbers. Integer overflows occur when an arithmetic operation exceeds the representable range, posing security risks, especially in scenarios where attackers exploit them for buffer overflows. • Format String attacks: Emscripten’s printf prints to the JavaScript console and can be exploited through format string vulnerabilities, potentially allowing attackers to read or write memory. Attempts to write to memory using such vulnerabilities may cause runtime exceptions and heap corruption, requiring reverse engineering for further investigation. • Stack-Based Buffer Overflows: Stack-based buffer overflows in Wasm occur when unsafe functions like strcpy overwrite local variables, as there are no protections within linear memory. This can lead to writing beyond allocated bounds, potentially enabling severe exploitation scenarios. • Vulnerability analysis of Wasm binaries: Since Wasm was designed to be a polyglot compilation target, it supports multiple programming languages, including type-unsafe languages such as C/C++. Given this fact, Wasm binaries compiled from unsafe languages may contain memory corruption vulnerabilities that make them susceptible to classical buffer overflow attacks. Recent work shows that memory vulnerabilities in unsafe source languages can propagate to WebAssembly binaries and may sometimes be exploited even more easily than native binaries. While this prior work evaluates the risks of such attacks on a small set of 26 binaries, most of which are compiled C/C++ benchmarks, it remains unclear to what extent propagated vulnerabilities may affect real-world WebAssembly binaries. Three important characteristics of binaries that attackers can abuse are the following: 1. Usage of Unmanaged Stack: The unmanaged stack is a region within the linear memory 76 of a WebAssembly program that holds, e.g., non-primitive data with function lifetime. This design is motivated by the fact that all non-scalar data and all data of which an address is taken cannot be put in WebAssembly’s locals or globals, but must instead reside in linear memory. Many binaries and functions in those binaries use the 72 M. Vassena and M. Patrignani, “Memory safety preservation for webassembly,” arXiv preprint arXiv:1910.09586, 2019. 73 J. Sun, D. Cao, X. Liu, Z. Zhao, W. Wang, X. Gong, and J. Zhang, “Selwasm: A code protection mechanism for webassembly,” in 2019 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Big Data & Cloud Computing, Sustainable Computing & Communications, Social Computing & Networking (ISPA/BDCloud/SocialCom/SustainCom). IEEE, 2019, pp. 1099–1106. 74 E. Johnson, D. Thien, Y. Alhessi, S. Narayan, F. Brown, S. Lerner, T. McMullen, S. Savage, and D. Stefan, “Доверяй, но проверяй: Sfi safety for native-compiled wasm,” in Annual Network and Distributed System Security Symposium (NDSS), 2021. 75 B. McFadden, T. Lukasiewicz, J. Dileo, and J. Engler, “Security chasms of wasm,” NCC Group Whitepaper, 2018. 76 A sequential, byte-addressable array that a Wasm module uses for storing data.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 40 - August 31, 2025 unmanaged stack, which attackers may abuse for runtime exploitation and Buffer overflow could occur. 2. Statically-linked allocators: WebAssembly’s memory organisation is minimalistic. Besides the single linear memory section, which can be expanded at runtime with the memory.grow instruction, the language itself provides no built-in support for dynamic memory allocation. Subdividing the linear memory, e.g., to avoid fragmentation and to reuse the space of deallocated objects, needs to be handled by an allocator embedded into the binary by the compiler. In most implementations this is done by statically linking an allocator. However, alternative designs such as multiple modules sharing a common linear memory are also possible. Especially for binaries on the web and for smart contract platforms, code size is an important consideration, so developers can choose a lightweight allocator instead of the default allocator provided by the compiler. Those smaller allocators can lack important mitigations against heap metadata corruption, and yield powerful arbitrary write primitives for an attacker. WebAssembly binaries come with a variety of memory allocators, including many custom allocators, increasing the risk to include vulnerable allocators. If code size is the motivation to use custom allocators, then a more secure alternative could be a memory allocation or garbage collection API provided by the host environment. 3. Imports of Security-Critical APIs from Host Environment: To exploit a WebAssembly binary, an attack proceeds in two steps. The first step is compromising the state or behaviour of the WebAssembly binary itself, e.g., by exploiting an unsafe allocator or a buffer overflow on the unmanaged stack. The second step is actually performing the malicious action on the underlying system. The only way to do so, assuming VM implementations are bugfree and host security is perfect (which they are not), is to call functions imported into the WebAssembly binary from the host environment. For example, an attacker could pass an injected string on the unmanaged stack to an imported function. To estimate how often WebAssembly binaries use such security-critical host APIs, their imports should be analysed. Many binaries import potentially dangerous APIs from their host environment, which may allow compromised binaries, e.g., to inject arbitrary code or to write to the file system, as discussed by Hilbig et al. 77 . 4.2.4 Triggering Unexpected Behaviour There are several ways for an attacker to trigger an unexpected behaviour in Wasm: a. Redirecting Indirect Calls: This type of attack allows for executing code that normally would not be executed in a given context. An attacker may redirect an indirect call by overwriting an integer in linear memory that eventually serves as an index in the table section. This integer value may be a local variable on the unmanaged stack, part of a heap object, in a vtable, or even a supposedly constant value. WebAssembly has two mechanisms that limit an attacker’s ability to redirect indirect calls. First, not all functions defined in or exported into a WebAssembly binary appear in the table for indirect calls, but only those that may be subject to an indirect call. Second, all calls, both direct and indirect, are type checked. As a result, an attacker can redirect calls only 77 A. Hilbig, D. Lehmann, and M. Pradel, “An empirical study of real-world webassembly binaries: Security, languages, use cases,” in Proceedings of the web conference 2021, 2021, pp. 2696–2708.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 41 - August 31, 2025 within the equivalence class of functions of the same type, similar to type-based controlflow integrity. 78 b. Code Injection into Host Environment: WebAssembly modules can interact with their host environment in various ways to cause externally visible effects. One such way is to invoke the notorious eval function of a JavaScript host environment, which interprets a given string as code. To access eval, WebAssembly modules compiled via Emscripten can use, e.g., emscripten_run_script, then an attacker may inject malicious code by overwriting the argument passed to an eval-like function. c. Application-specific Data Overwrite: Depending on the application, there can be other sensitive targets for data overwrites. For example, a WebAssembly module issuing web requests through an imported function could be made to contact a different host by overwriting the destination string, to initiate cookie stealing. This kind of environment contains many opportunities for significantly altering program behaviour, e.g., by overwriting bytecode that is interpreted by the runtime. 4.3 System Interface Security A critical part of evaluating Wasm isolation is analysing the security of syscalls (hostcalls) exposed through the WASI interface. To perform meaningful operations, Wasm binaries require mechanisms for controlled interaction with their host environment. The original approach employs core modules that depend on host-provided import functions for all external interactions. Since these import functions are typically implemented with environment-specific bindings and system call wrappers, core modules exhibit poor portability characteristics—a module compiled for browser execution requires significant host-side modifications to operate on server runtimes or embedded systems. The early WASI 0.1 specification attempted to standardise these host interfaces by defining a common set of system-level imports, but provided only basic POSIX-like functionality with limited abstraction from underlying platform differences. The WebAssembly Component Model introduces a fundamentally different approach: instead of requiring environment-specific bindings and integration code, components define standardised interfaces that enable universal portability. Components use WIT (WebAssembly Interface Types) to specify language-agnostic interface contracts—explicitly declaring input and output data types without dependencies on host-specific implementations. Unlike core modules that rely on shared linear memory and require hosts to provide environment-specific import functions, components operate under a shared-nothing architecture, communicating exclusively through well-defined interface boundaries that enforce isolation. WASI 0.2 implements a capability-based security model where hosts grant granular resource permissions (e.g., file system access or network connections) through controlled interfaces rather than exposing direct system calls. This architecture achieves true write-once-run-anywhere deployment—a component developed for database integration can execute without modification across web browsers, server environments, or edge devices, as it depends only on its declared interface types rather than platform-specific runtime characteristics. The component-host relationship operates through a well-defined contract model where components contribute computational capabilities while requesting specific platform services through controlled interfaces. Rather than direct system access, components declare their resource requirements—file system operations, temporal services, environment variables, or network connectivity—which the host mediates through capability-based permissions. WASI 78 M. B. Mart’ın Abadi, ´U. Erlingsson, and J. Ligatti, “Control-flow integrity,” in Proceedings of the Conference on Computer and Communications Security, vol. 10, 2005, pp. 1 102 120–1 102 165.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 48 - August 31, 2025 • "Orchestrated" applications are described in a high-level form that will be used by a platform such as WasmCloud 82 to distribute application components to different physical machines to be executed by independent Wasm runtimes, and then connected at runtime using a mechanism such as wrpc. 83 Both models can be used to describe the same application, 84 which will have the same behaviour despite very different representations. Even within the same model, multiple representations of the same application may exist, such as if a composed application includes its components in a different order, or if it is optimised by deduplication of component definitions. Our goal, therefore, is to devise a canonical representation of an application that is independent of these variations, allowing its identity to be described for purposes such as access control or remote attestation. Our first observation is that a Wasm component does not have any runtime state of its own; rather, the component defines concrete entities such as memories and modules that will be instantiated by the runtime. As a result, the structure of a component does not in itself have any bearing on its behaviour when instantiated; this behaviour is identical to that of a flattened representation of the component, in which each concrete entity is instantiated and linked at the top level of the component. The behaviour of the component is therefore determined by the instance graph, with nodes representing module and memory instances, and edges representing the connections between them as constructed by the linker. We have extracted this graph from a component binary, and will use it to construct a canonical representation of the application. This first step will enable a Wasm runtime inside a trusted execution environment to construct a component-model-aware measurement of the application that it is running. The next step is to integrate these measurements from different components, allowing us to represent a distributed system as a whole, and in combination with distributed attestation techniques developed in WP3, to attest entire orchestrated applications spread across many physical machines. 4.4.2 Migration In the previous section, we described the instantiation of an application in a relatively static manner. However, real applications are executed in a dynamic environment, with traffic volumes changing constantly, and underlying hardware platforms coming and going. Horizontal scaling of stateless services can accommodate some of these variations, but in other cases we have no choice but to migrate components with persistent state from one place to another, permanently changing the deployment of the application. Adapting to these changes brings a number of challenges. In order for the application to function correctly, all of its components must remain connected to one another in a globally consistent way, but achieving such global consensus comes with a significant and potentially unacceptable runtime cost. However, migration in its simplest form is a somewhat special case, since only a single entity in the system can be responsible for any given role; therefore, a secure two-party protocol guaranteeing that at all times only a single entity, running the correct software, will be able to participate in the application as a particular component instance, will also guarantee that the migration does not compromise the security of the application. 82 https://wasmcloud.com 83 https://github.com/bytecodealliance/wrpc 84 Orchestration platforms may include functionality beyond that of the basic component model, so this may not always be the case for every application, e.g., where a component being used in the function-as-a-service is scaled to large numbers of instances at runtime.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 49 - August 31, 2025 A previous solution 85 proposed the use of a probabilistic fair-exchange protocol to ensure the atomicity of Wasm migration, but a simplistic solution such as this is limited in real-world usage, as the performance-security trade-off is heavily in favour of the attacker, with their probability of success only decreasing linearly with the number of rounds of messages. We are investigating an alternative solution using a three-party protocol based on secret sharing, that will use a TEE elsewhere in the cloud platform to facilitate completion of the protocol in the event that one party fails to follow the protocol correctly or the network is disrupted. This allows for a security level more typical of purely-cryptographic solutions with only a few rounds of communication. The two parties use the protocol to ensure that either the destination receives the component's identity key and the source receives a receipt proving that it is no longer responsible for the component, or that the protocol aborts with no party receiving anything. 4.5 ELASTIC WebAssembly Research Questions As a result of our initial investigation, we have identified a number of research questions for consideration in subsequent tasks. Sandbox security • Do implementations of the Wasm VM correctly enforce the memory constraints as specified in the spec? How to be assured of this? (T1.2) • What memory attacks are possible against Wasm applications? How do they compare to exploitation possibilities present in native binaries? (T1.2) • Can we provide protections against these memory attacks using Wasm mechanisms? (T1.2) Wasm interfaces • Are WASI APIs defined with enough precision to be secure and to be implemented with the same behaviour across multiple runtimes? (T1.2) • Do implementations of WASI APIs correctly follow the specification and follow good security practices? (T1.2, T1.4) • How can we give Wasm applications awareness of the outside world using sensors such as temperature, position, etc. (T1.4, T2.1, T4.1) • Can filtering be integrated with existing access control mechanisms to allow complex capabilities, e.g., so that an application can write to an I2C bus, but only write certain commands to certain addresses? (T1.2, T1.4) Distributed systems • How can we migrate resources in a Wasm-based system without compromising their integrity? (T1.2, T3.2, T3.3)? • How can we meaningfully authenticate interfaces on remote machines? (T1.2, T1.4, T3.2, T3.3) 85 Wojciech Geisler, Reliable Migration of WebAssembly Trusted Applications, Master’s thesis, 2018.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 50 - August 31, 2025 5 eBPF & XDP This section will introduce the extended Berkeley Packet Filter (eBPF) technology of the Linux kernel, first through a generic technical overview of its capabilities and design, and then followed by a deeper investigation of the eXpress Data Path (XDP) and other Linux Kernel Network Stack (LKNS) hooks, discussing how they are often used to improve network performance and observability. Finally, the security of the eBPF runtime is considered, together with a detailed report on the current performance of eBPF when used to accelerate specific applications such as traffic capture and service mesh packet routing. 5.1 Introduction to eBPF and XDP eBPF is a Linux kernel technology that allows userspace applications to extend the kernel’s capabilities by attaching small programs to specific events. Among other things, eBPF has been used to create observability tools, load balancers, and container security frameworks. What makes eBPF so powerful is that eBPF programs can be hooked into almost anywhere in the kernel, where they can monitor and control core parts of the system. Typically, eBPF programs are written in C or other system-level programming languages, and compiled to bytecode that can later be JIT-compiled. This enables eBPF programs to be portable between different kernel versions. There are many types of eBPF programs with different capabilities and purposes, but some of the important ones are the following. • XDP (eXpress Data Path) and TC (Traffic Control) eBPF programs can read, modify, and redirect network traffic and are used to implement networking functionality such as load balancers, firewalls, and monitoring tools. • Kprobes, kretprobes, uprobes, and uretprobes allow eBPF programs to attach to arbitrary functions in the kernel as well as in userspace code such as executables and libraries. They can read kernel and userspace memory, and retprobes can modify the return value of the function they attach to. • LSM eBPF programs can attach to LSM hooks and read kernel and userspace memory, including details of the attempted access. Similarly to how LSMs behave, they have the ability to deny access attempts. Typically, eBPF programs communicate with userspace through the use of ring buffers and maps. eBPF offers functionality by which these collections can be created and maintained within the kernel, where they can be accessed and modified by both userspace and eBPF programs. After attaching an eBPF program to the execve kprobe, it will be invoked every time a program uses the execve system call. Each time it is invoked, the program will write an event consisting of the calling process’ PID and command to the ring buffer, where it can be consumed by a userspace program. Programs are compiled to eBPF bytecode by so called “eBPF backends”; two such compilers are currently available in the ecosystem: LLVM and the Gnu Compiler Collection (GCC), with the former being the de-facto standard, as the eBPF target for GCC is younger and largely considered immature. Once the eBPF object file is obtained, the Linux bpf system call 86 can be used to load the program in the kernel and attach it to the desired event. The bpf syscall is the only interface between the kernel eBPF subsystem and the user-space domain, and as such 86 The Linux Kernel developers, “eBPF Syscall,” The Linux Kernel documentation. https://docs.kernel.org/userspaceapi/ebpf/syscall.html (accessed Jun. 13, 2025).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 51 - August 31, 2025 it is heavily overloaded to expose all the various operations that eBPF supports, i.e., program loading, attaching, map creation and lookup, etc. This makes interacting with the bpf syscall inconvenient and potentially harmful to code portability between kernel versions, as the eBPF ecosystem continues to evolve rapidly. Instead, programmers typically rely on higher level abstractions to more effectively develop eBPF applications. Some of the most popular frameworks are described in the following. • libbpf. libbpf 87 is a C library that is developed alongside the main Linux kernel, and as such it always supports the latest innovations and updates of the Linux eBPF runtime. Together with the C source of the library, an official idiomatic Rust binding is also maintained, allowing the use of the memory-safe programming language for the control plane of eBPF applications. • aya. aya 88 is an independent Rust library crate that facilitates developing eBPF applications using Rust for both their userspace and kernel-space components. Due to its Rust-native conception, it offers a natural and idiomatic async API supporting most common async runtimes. Because of the independent nature of this project, it is likely that cutting edge features of the latest kernels might not be supported, making aya impractical for writing state-of-the-art code. • BCC. The Bpf Compiler Collection 89 provides an assortment of tools and facilities for building eBPF proof-of-concepts and prototypes with a focus on simplicity. It officially supports the C language for writing the eBPF code, and Python and Lua for the userspace frontend. Unlike the previous frameworks, BCC enforces that the C code be compiled to eBPF at program loading time, potentially slowing down the startup time of the program and making BCC inadequate for the distribution of eBPF tools. 5.2 eBPF for Networking Among the many uses that eBPF-based technology has found in several fields of IT design and infrastructure, networking is undoubtedly a primary one, supported by the wide range of dedicated eBPF attach points in the Linux kernel networking stack (LKNS), such as XDP and TCX. Within the vast field of network performance tuning, eBPF was proven to be beneficial to multiple different uses cases. The following subsections elaborate on how the use of eBPF acceleration was advantageous for cluster networking, high-performance packet drop and redirection, as well as in-kernel application-level offload. 5.2.1 Cluster Networking Cluster networking is networking applied to computing clusters, such as Kubernetes, where CNI (Container Networking Interface) plugins are used to provide communication capabilities between pods and services. These kinds of orchestrators typically rely on containerisation technology to run application workloads due to their balance between isolation and performance overhead. From the perspective of cluster networking, isolation is achieved through the use of NetNSs (Network NameSpaces): each container is assigned a dedicated NetNS, and all processes within it run in the context of that namespace. In practice, this equates to a duplication of all network stack resources, making network namespaces effectively behave as isolated network devices. Exchange of traffic between containers can happen via special 87 The Linux Kernel developers, “libbpf Overview,” The Linux Kernel documentation. https://docs.kernel.org/bpf/libbpf/libbpf_overview.html (accessed Jun. 13, 2025). 88 Aya open source developers, “Aya homepage.” https://aya-rs.dev/ (accessed Jun. 13, 2025). 89 “BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more,” Github. https://github.com/iovisor/bcc (accessed Jun. 13, 2025).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 52 - August 31, 2025 virtual devices called Virtual Ethernet (or “veth” in short), which function as Ethernet cables whose two ends relay all received packets to their peer; when the linked ends of a veth pair are owned by two different network namespaces, they can route traffic through them to achieve communication. Although this is an effective and elegant solution to allowing network communication between isolated computing containers, this mechanism also incurs an additional CPU overhead due to the addition of an extra hop within the virtual network fabric of the cluster’s nodes: packets originating from an external client or node must in fact be first received by the physical network interface, which is typically assigned to the “main” NetNS. Once in the receive network stack processing pipeline, virtual bridging or routing primitives are used to forward the packet to the veth device of the destination container, thus resulting in a duplication of work, as the packet must be received a second time in the final network namespace. Similarly, for traffic flowing between two containers on the same cluster node, packets are usually routed through the main NetNS, once again causing an increase in processing time. Since the introduction of eBPF in the Linux kernel, and thanks to its constant evolution and improvement, few CNI plugins have been proposed that make use of eBPF programs to enhance container networking. Among these, Isovalent’s Cilium 90 is undoubtedly the most invested in the eBPF ecosystem. Here are some of the ways in which the Cilium CNI plugin employs eBPF to improve container networking performance: • eBPF host routing. When packets are received from a network-facing Network Interface Card (NIC), and directed towards a containerised application, two network stacks must be traversed before the packet reaches the destination socket: the one associated with the main NetNS, and that of the application container. This is inefficient due to the double invocation of all NetFilter input hooks, as well as the expensive Conntrack accounting; additionally, the network namespace switch happens over the CPU backlog queue, implying an additional SoftIRQ-to-SoftIRQ context switch, which is bound to increase latency. Cilium’s “eBPF host routing” is a custom packet pipeline entirely based on eBPF that aims at mitigating this overhead without sacrificing application isolation. In Ciliumpowered clusters, an eBPF program is attached to the Traffic Control (TC) Ingress hook of all physical network devices. This is triggered for each received packet coming from the external network, and serves as the entry point to the eBPF host routing stack. Within the TC probe, eBPF code has full access to the packet’s content, as well as most of its metadata fields. When a packet’s destination IP address is that of a local container, the eBPF host routing stack uses the bpf_redirect_peer() eBPF helper to forward that packet directly to the container side of the application’s veth pair, skipping both the main NetNS processing and the costly context switch. For outbound packets produced by containerised applications, the eBPF host stack is only able to avoid traversing the main NetNS (with the bpf_redirect_neigh() helper), since Cilium cannot attach eBPF programs to the container-side of veth pairs. • The Netkit virtual device. To mitigate this limitation of the eBPF host routing transmit stack, Isovalent developed the Netkit 91 driver as a replacement of veth for container clusters. Like veth, Netkit behaves as an interface pair, allowing traffic to flow between otherwise isolated network namespaces, though it extends traditional virtual Ethernets by offering a built-in eBPF control mechanism. Netkit interfaces are in fact designed to 90 “Cilium - Cloud Native, eBFP-based Networking, Observability, and Security.” https://cilium.io/ (accessed Jun. 13, 2025). 91 “Cilium netkit: The Final Frontier in Container Networking Performance.” https://isovalent.com/blog/post/cilium-netkit-anew-container-networking-paradigm-for-the-ai-era/ (accessed Jun. 13, 2025).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 53 - August 31, 2025 be provided with an eBPF program as part of their configuration; this program is then run for each packet transmit event, giving users the ability to inspect traffic, alter it, and redirect it to other interfaces. Crucially, Netkit distinguishes between the host side and the container side, such that eBPF configuration is only allowed through its host side. This enables Cilium to steer outbound traffic directly in the application’s namespace rather than having to wait for the packet to reach the main one, without needing to interfere with the container’s eBPF environment. • kube-proxy replacement. Services represent one of the core resources of the Kubernetes orchestration model. In the most common deployments, a service is described by a Virtual IP (VIP) address and a set of backing endpoints; the Kubernetes infrastructure is then responsible for steering network packets addressed towards a service’s VIP to one of its underlying backend addresses in a rotating manner. This achieves both a load-balancing function, as well as detach an API or microservice from the container on which it is hosted (which is often assigned an ephemeral IP address), helping discoverability and resilience. kube-proxy is the per-node process that is responsible for ensuring that incoming requests to a service’s VIP are routed to one of its available endpoints. This always involves destination NATting (DNAT) of the request packets (i.e., replacing the destination IP with the concrete address of one of its endpoints), though it also requires masquerading (SNAT) whenever the selected endpoint is hosted on a different node of the cluster, to ensure that return traffic is correctly de-natted. As both DNAT and SNAT are normally implemented as NetFilter rules, kube-proxy uses Iptables to configure them for all services in the system. This creates some large inefficiencies when many services are instantiated, due to the fact that Iptables rules are applied sequentially, harming scalability. To counteract this, Cilium offers a kube-proxy replacement mode, where the custom eBPF stack is used instead for service address resolution. Owing to the high-performance hash maps available to eBPF code, scalability over the total number of services is greatly improved. Moreover, Cilium supports an optional XDP acceleration 92 mode that enhances their eBPF-based kube-proxy replacement by performing early redirection of packets headed towards a service endpoint in a different node Finally, the Calico eBPF CNI plugin 93 implements kube-proxy replacement as a way to avoid the source IP address masquerade, which might hinder some applications. 5.2.2 Early Packet Drop/Redirection Another important application of eBPF is efficient packet dropping and redirection. Thanks to the early position of the eXpress Data Path hook point in the LKNS receive path, packets can be redirected or dropped before the kernel has a chance to spend any CPU cycles on them. The act of utilising alternative technology to skip the regular kernel packet processing stack is often referred to as “kernel bypass”, and it is known to give large performance speedups when used to implement traditional or custom network functions alike. Compared to its competing solutions – such as DPDK, Netmap, and others – XDP offers kernel bypass capabilities without needing to dedicate an entire network interface to the custom code, meaning that the same NIC can be used for receiving both packets that need to be processed via the kernel bypass pipeline, as well as those which are to be forwarded to the kernel stack for delivery to applications. 92 “Tuning guide: XDP Acceleration,” Cilium documentation. https://docs.cilium.io/en/stable/operations/performance/tuning/#xdp-acceleration (accessed Jun. 13, 2025). 93 “eBPF Data Plane,” Calico features. https://www.tigera.io/features/ebpf-data-plane/ (accessed Jun. 13, 2025).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 54 - August 31, 2025 Meta exploited the advantages offered by XDP when designing their next generation Katran layer-4 load balancer 94 (L4LB). Compared to its predecessor, Katran can improve server consolidation of their data centre infrastructure by hosting both the load balancer and the backend application on the same hardware, which was previously impossible on their earlier IPVS-based system. Meta is using XDP for packet redirection and rewriting, thus exploiting two of its most prominent strengths. Additionally, Katran can fall back to XDP Generic mode whenever Native is not available, ensuring maximum compatibility across NIC drivers. Cloudflare has also shown great interest in eBPF technology through their L4Drop 95 project, which is the main data plane component of the Distributed Denial of Service (DDoS) mitigation system that is currently in place in their extensive fleet of data centres. Any inbound packet received through one of Cloudflare’s gateway nodes will go through L4Drop’s XDP code, where it is matched against a set of rules before potentially being dropped. Furthermore, L4Drop will sample a subset of all incoming packets for inspection, which are sent to an internal component that is responsible for estimating incoming attacks and generating defensive packet filters against them; the filters are then converted to C code and compiled to eBPF as the next iteration of the L4Drop’s XDP backend. As such, L4Drop can competently track changing attach patterns, maintaining effectiveness. Overall, Cloudflare notes that L4Drop is able to handle millions of packets per second while minimally increasing the CPU consumption of the host, achieving great levels of efficiency. Finally, it is worth noting that eBPF/XDP is often used to reimplement components of the traditional Linux networking environment in order to improve performance, scalability or overall effectiveness, providing alternative versions of classic tools or drivers. This is the case, for example, with bpf-iptables which, as part of the polycube 96 ecosystem, offers an evolution over the iptables firewall based on XDP and TC eBPF programs. Thanks to the earlier position of the XDP hook point compared to Netfilter’s filter table chains, as well as the use of an ingenious packet matching algorithm, bpf-iptables outperforms traditional iptables by more than ten times as the number of filtering rules grows large, as iptables needs to linearly iterate over them to match packets. 5.2.3 In-kernel Application Offload Finally, eBPF is often used as an in-kernel application cache or offload to speed up the business logic of the target application by shortcutting user requests or reducing user-kernel context switches. This is especially beneficial for networking applications due to the extensive eBPF packet interception instrumentation that has already been built into the Linux kernel. Some notable examples from the literature include the BPF Memcached Cache (BMC), 97 which proposes an eBPF-based fast path for the popular in-memory key-value store memcached. By using a set of XDP programs in the kernel, BMC can intercept UDP GET and TCP SET user requests directed to the database before the Linux network stack is invoked. Exploiting an inkernel mirror of the main cache based off of linear eBPF maps, BMC can thus fulfil most GET requests without involving the user-space memcached process at all; only kernel cache misses result in the request packet traversing the network stack and being served by memcached. 94 The Meta developers, “A high performance layer 4 load balancer,” Github. https://github.com/facebookincubator/katran (accessed Jun. 13, 2025). 95 Cloudflare, “L4Drop: XDP DDoS Mitigations,” The Cloudflare Blog. https://blog.cloudflare.com/l4drop-xdp-ebpf-basedddos-mitigations/ (accessed Jun. 13, 2025). 96 “Polycube: eBPF/XDP-based software framework for fast network services running in the Linux kernel.,” Github. https://github.com/polycube-network/polycube (accessed Jun. 13, 2025). 97 Y. Ghigoff, J. Sopena, K. Lazri, A. Blin, and G. Muller, ‘BMC: Accelerating Memcached using Safe In-kernel Caching and Pre-stack Processing’, in 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21), 2021, pp. 487–501.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 55 - August 31, 2025 Similarly, response packets generated by the memcached process are intercepted by a TC egress eBPF probe which is responsible for updating the main in-kernel cache. By attaching code to an interface’s XDP hook, that code is run within the NAPI (formerly “New API”) poll invocation of such interface, which – for modern NICs supporting Receive-Side Scaling (RSS) technologies over multiple receive queues – allows it to naturally scale over multiple CPU cores as different queues are polled concurrently by the Linux network stack. This contributes to the outstanding 18x throughput improvement that BMC provides compared to the baseline memcached performance when using eight total cores. Moreover, BMC still compares favourably to full kernel bypass, as it achieves higher requests-per-second performance while consuming lower amounts of CPU resources (thanks to its interrupt-based operation) than seastar-memcached, a version of the database program based on the Seastar high-performance I/O framework. Electrode 98 applies eBPF application offload to distributed protocols, frequently used for replicated database synchronisation and more. Specifically, Electrode targets the Multi-Paxos consensus algorithm, which necessitates frequent communication between the networked replicas to achieve a consensus and satisfy user requests. Traditionally, user-space implementations of the protocol require that the transaction leader broadcast messages to all other followers before starting to listen for acknowledgements. This incurs several expensive context switches, and runs into high network stack overhead, which is found to be the dominating factor of the protocol’s time budget. Electrode mitigates these inefficiencies by using eBPF to implement three key optimisations to the algorithm. First, the bpf_clone_redirect() helper is used in a traffic control egress eBPF probe to improve broadcast throughput: the Paxos process now only needs to send a single message (and thus pay the cost of the user-to-kernel transition and most of the kernel stack overhead only once) and have eBPF replicate and transmit it to all followers. Second, the Paxos protocol logic and acknowledgement generation is moved into an eBPF/XDP program at the followers to enable fast acknowledgement of preparation messages, hence completely skipping the traversal of the input network stack for these packets. Finally, eBPF is used to reduce the number of wakeups of the user-space leader process when waiting for acknowledgements, once again making use of the XDP hook. Combined, these optimisations lead to more than doubling the throughput and almost halving the latency compared to a fully userspace implementation of the MultiPaxos protocol on a seven-replica cluster. The Cilium service mesh 99 is an extension of the Cilium CNI plugin for Kubernetes that adds typical service mesh capabilities such as L4-L7 policy enforcement, endpoint authentication, intra-cluster traffic encryption, and more. Unlike other service mesh providers, Cilium can offer many of these features without relying on an explicit sidecar process, by instead offloading the functionality to eBPF probes, as well as relying on kernel-based encrypted tunnels instead of the more commonly used TLS. While complex policies or filtering rules still require the use of a proxy sidecar, Cilium can avoid redirecting all traffic through it if not necessary, saving important CPU cycles. A more thorough investigation of the capabilities and performance of the Cilium service mesh, together with a general look into eBPF data planes for service mesh implementations, will be part of Deliverable 1.3, though a preview is also presented in Section 4.5. 98 Y. Zhou, Z. Wang, S. Dharanipragada, and M. Yu, ‘Electrode: Accelerating Distributed Protocols with eBPF’, in 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), 2023, pp. 1391–1407. 99 “Cilium Service Mesh.” https://cilium.io/use-cases/service-mesh/ (accessed Jun. 13, 2025).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 56 - August 31, 2025 5.3 eBPF for Observability This section provides an overview of the eBPF observability landscape by categorising related tools into three main groups, including network monitoring tools, performance profiling tools, and security detection tools. The contributions in this section are published also in publicly available master thesis 100 . 5.3.1 eBPF-based Network Observability Tools This subsection provides an overview of the eBPF-based network observability tools currently available. Cilium 101 (with Hubble 102 ): Cilium is an open-source, cloud-native solution that provides, secures, and observes network connectivity between workloads. It is equipped with a built-in module, called Hubble, to support network observability. Hubble, powered by eBPF, enables real-time visibility into network traffic, providing detailed information about the source, destination, and type of traffic flowing through the cluster. Specifically, Hubble offers metrics and traces of flows at the network and application protocol level, including TCP connections, DNS queries, and HTTP requests and responses. Pixie 103 is an open-source observability tool for Kubernetes applications. It uses eBPF to automatically collect telemetry data without manual instrumentation, and it provides a set of community scripts for common use cases. With respect to network observability, it supports tracing the flow of network traffic within a K8s cluster, the flow of DNS requests within a cluster, and TCP drops and TCP retransmits across a cluster. Retina 104 is a cloud-agnostic, eBPF-based open-source Kubernetes network observability platform that provides a centralised hub for monitoring application and network health and security. It leverages eBPF technologies to collect and provide insights into the Kubernetes cluster with minimal overhead. It provides Nodeand Pod-level network metrics related to TCP/IP connections, UDP connections, DNS requests, etc. It also allows users to capture network traffic for specified Nodes/Pods. Caretta 105 is a Kubernetes service map that uses eBPF to trace network traffic between pods. It can be used to visualise the network traffic between services in a Kubernetes cluster, and gain additional insights into the network traffic and the relationships between services. Beyla 106 is an open-source eBPF-based auto-instrumentation tool that helps users easily get started with application observability for Go, C/C++, Rust, Python, Ruby, Java, NodeJS, .NET, and more. It uses eBPF to automatically inspect application executables and the OS networking layer, allowing users to capture essential application observability events for HTTP/S and gRPC services. Groundcover 107 is a full stack, cloud-native observability platform. It uses eBPF to provide visibility of network events in Kubernetes clusters. Unlike many other solutions which rely on 100 Yinan Hu, “Observability for Serverless Wasm Workloads using eBPF”, M.S. thesis, Dept. of Computer Science, Aalto University, Espoo, Finland, unpublished manuscript (to be published during Fall 2025). 101 “Cilium Service Mesh.” https://cilium.io/use-cases/service-mesh/ (accessed Jun. 24, 2025). 102 “Hubble.” https://github.com/cilium/hubble (accessed Jun. 24, 2025). 103 “Pixie.” https://px.dev/ (accessed Jun. 24, 2025). 104 “Retina.” https://retina.sh/ (accessed Jun. 24, 2025). 105 “Caretta.” https://github.com/groundcover-com/caretta (accessed Jun. 24, 2025). 106 “Beyla.” https://grafana.com/oss/beyla-ebpf/ (accessed Jun. 24, 2025). 107 “Groundcover.” https://docs.groundcover.com/?_gl=1*jkw414*_gcl_au*MTUwNDQ5NTMyLjE3NDIyMTg4ODQ. (accessed Jun. 24, 2025).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 57 - August 31, 2025 an external tool for logs (e.g., the oTel collector), Groundcover leverages eBPF to natively generate logs from observed workloads. Coroot 108 is an open-source eBPF-based observability tool for Kubernetes. It uses eBPF to automatically gather observability data and provides application health summary. Regarding networking observability, it gathers the metrics, traces, and logs of network connections of nodes. DeepFlow 109 aims to provide deep observability for complex cloud-native and AI applications. It implements zero-code data collection with eBPF for metrics, distributed tracing, request logs, and function profiling. Regarding network observability, it offers traces and metrics of network traffic and profiles of network functions. Additionally, it supports logging of network flows. RustiFlow 110 is a flow feature extraction tool built in Rust using eBPF. Leveraging Rust language and eBPF, it excels in processing high volumes of network traffic with high performance. It also supports packet analysis. Google Kubernetes Engine (GKE) Dataplane V2 111 is a dataplane that is optimised for Kubernetes networking, implemented using eBPF. It leverages eBPF and Cilium to support Kubernetes Network Policy logging. Network Observability eBPF Agent 112 is an eBPF agent that allows collecting and aggregating all the ingress and egress flows on a Linux host. It empowers the collection of essential network metrics, including network flow statistics. eCapture 113 is an SSL/TLS capture tool using eBPF. It provides TLS communication observation by capturing SSLKEYLOG and plaintext communications from OpenSSL and GnuTLS. Kyanos 114 is a networking analysis tool using eBPF. Powered by eBPF, it supports traffic filtering based on IP/port information, process or container, L7 protocol information, request or response byte size, latency, etc. Also, it provides fine-grained packet capture and advanced packet analysis. In addition, it can provide in-depth kernel-level details of network latency. Pwru 115 is an eBPF-based tool for tracing network packets in the Linux kernel with advanced filtering capabilities. It allows fine-grained introspection of kernel state to facilitate debugging network connectivity issues. Alaz 116 is an open-source Anteon eBPF agent that can inspect and collect Kubernetes service traffic without the need for code instrumentation, sidecars, or service restarts. It monitors K8s service interactions and performance metrics in the Kubernetes environment, provides in-depth insights with service maps and metrics, and supports alerts to crucial system anomalies. KubeSkoop 117 is a network diagnosis and monitoring suite for Kubernetes and supports multiple CNI plugins and IaaS cloud providers. It uses eBPF for offering visibility into the 108 “Coroot.” https://coroot.com/ (accessed Jun. 24, 2025). 109 “Deepflow.” https://github.com/deepflowio/deepflow (accessed Jun. 24, 2025). 110 “RustiFlow.” https://github.com/idlab-discover/RustiFlow (accessed Jun. 24, 2025). 111 Google Cloud, “Bringing eBPF and Cilium to Google Kubernetes Engine.” Google Cloud Blog. https://cloud.google.com/blog/products/containers-kubernetes/bringing-ebpf-and-cilium-to-google-kubernetes-engine (accessed Jun. 24, 2025). 112 “Network Observability eBPF Agent.” https://github.com/netobserv/netobserv-ebpf-agent (accessed Jun. 24, 2025). 113 “eCapture.” https://ecapture.cc/ (accessed Jun. 24, 2025). 114 “Kyanos.” https://kyanos.io/ (accessed Jun. 24, 2025). 115 “Pwru.” https://github.com/cilium/pwru (accessed Jun. 24, 2025). 116 “Alaz.” https://github.com/getanteon/alaz (accessed Jun. 24, 2025). 117 “Kubeskoop.” https://kubeskoop.io/ (accessed Jun. 24, 2025).
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 64 - August 31, 2025 Table 4: qualitative comparison of eBPF-based security observability tools Tool/ Framework Observabili ty Target eBPF-based Network Observability Features Network Traces Network Metrics Network Logs Network Anomaly Detection License Tetragon (v1.4.0) Kubernetes Traces TCP connections Yes No Yes Yes Apache2.0 license Falco (0.40.0) Linux hosts, containers, Kubernetes Network flow monitoring and anomaly detection No No Yes Yes Apache2.0 license SysmonForLi nux (1.3.7) Linux Supports TCP/UDP network connections tracking No No Yes Yes MIT license Puslar (v0.9.0) Linux Supports TCP/UDP connections tracing Yes No Yes Yes Apace2.0 License or GPL2.0 license Kflow (v0.9) Linux Supports tracing of TCP, and UDP networking events No No Yes Yes GPL-2.0 license An Anomaly Detection Approach by AIML in IP Networks with eBPFBased Observability Routers (Linux) Metrics and anomaly detection of TCP traffic No Yes No Yes N/A QoS-Aware Congestion Control using using SRv6 Linux QoS classes for network traffic and congestion avoidance No Yes No No N/A 5.4 Security Aspects of eBPF eBPF is very powerful, but at the same time security-critical since it enables running userprovided code in the kernel, which is obviously dangerous for the OS integrity and security. For this reason, eBPF was endowed with security mechanisms designed to counter the main possible threats, but such mechanisms are not perfect and have their own vulnerabilities. This section presents an overview of the security aspects of the eBPF system, mainly based on a systematic scientific literature review. The goals are: 1. to identify the most important threats, vulnerabilities, attack surfaces, and exploitation techniques of the eBPF system; 2. to identify the main techniques that have been proposed to mitigate the eBPF system security issues. First, in Subsection 5.4.1, the eBPF security features and mechanisms will be summarised. Then, in Subsection 5.4.2, the methodology adopted for the systematic literature review will be presented. Subsection 5.4.3 will then present the classification of the papers found in the review, and Subsection 5.4.4 will present the threats, vulnerabilities, attack surfaces, and exploitation techniques documented in the papers. Finally, Subsection 5.4.5 will present the known mitigation techniques. The last Subsection (5.4.6) will present other security aspects related to eBPF and hardware platforms. Based on the work done within Task T1.3, Section 6.1 will then present a deeper analysis of eBPF code security aspects based on other kinds of studies, such
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 65 - August 31, 2025 as the analysis of eBPF-related Common Vulnerabilities and Exposures (CVE), exploits, rootkits, and specific tests. 5.4.1 eBPF Security Mechanisms The security mechanisms of eBPF are centered around several key components that work together to protect the kernel from potential exploits. The most important of these is the eBPF verifier, which plays a critical role in ensuring that eBPF programs are safe and secure to run within the kernel, and that they do not infringe upon the eBPF security model. The verifier performs static analysis of eBPF code to ensure it adheres to strict safety and correctness rules. It checks for various issues such as memory safety (preventing out-of-bounds memory access and restricting access to certain memory regions only), kernel isolation from user space, proper program termination, and ensures that the program does not attempt to perform unauthorised actions or access kernel memory in an unsafe or insecure manner. While making these checks, the verifier also simulates the program’s execution to ensure that it behaves correctly under all possible conditions, preventing issues such as infinite loops or crashes. Additionally, eBPF’s security relies heavily on privilege control. By default, in the latest Linux distributions, only privileged (root) users can load eBPF programs into the kernel. This setting was introduced after the discovery of several different attacks by which unprivileged users could bypass system protections and isolation mechanisms and escalate privileges. In this way, untrusted or malicious unprivileged users are prevented from executing potentially harmful code. This helps maintain system integrity by limiting access to the sensitive resources of the kernel to privileged users only. However, this default can be changed, allowing unprivileged users to load eBPF code. As the use of eBPF by unprivileged users is attractive due to the many possible useful applications it enables, there could be systems where the default is changed to allow this use. In particular, the CAP_BPF capability is required to load eBPF programs, which grants control over loading and attaching eBPF to various hooks in the kernel. This capability has been introduced as a way to ensure that only trusted users or processes with appropriate privileges can make changes to kernel behaviour. When eBPF is used in a non-privileged context, additional subsystem-specific capabilities are required in order to attach the eBPF program to a triggering event: for example, attaching an eBPF program to a network application requires the CAP_NET_ADMIN capability. The required capabilities are checked at load time during verification. 5.4.2 Systematic Literature Review Methodology To investigate the security aspects of the eBPF system, we conducted a systematic literature review (SLR). The goal of the review was to identify the most relevant and recent academic and technical contributions related to eBPF security, including threats, vulnerabilities, attack techniques, and mitigation strategies. The SLR was carried out by querying the most widely recognised digital libraries, including ACM Digital Library, IEEE Xplore, USENIX, and Scopus. The same keyword string was used across all platforms to ensure consistency in the search process: (ebpf OR bpf) AND (security OR attack OR attacks OR vulnerability OR vulnerabilities OR safety OR safe OR unsafe OR CVE OR CVEs) This query was intentionally broad to capture a wide range of publications that could potentially discuss security-relevant aspects of eBPF. The initial search returned a total of 302 papers.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 66 - August 31, 2025 Each paper was then screened manually based on title, abstract, and — when necessary — the full text, to determine its actual relevance to the specific goals of the review. In some cases, additional relevant papers not included in the search results were found among the references of the relevant search results. The scientific papers found through the search can be broadly classified into three main categories: 1. Studies that explore how eBPF can be used to implement or enhance system security measures or, conversely, be used for malicious purposes, such as concealing the attackers’ activities after the exploitation of system vulnerabilities (security with eBPF). 2. General discussions around the adoption and evolution of eBPF, often highlighting its value in system and network operations, while occasionally touching on associated security risks. 3. Research explicitly analysing the security of the eBPF system itself, focusing on its internal vulnerabilities and potential weaknesses (security of eBPF). While the first category is the most represented in the literature due to the practical utility of eBPF in improving system observability and control, it falls outside the main scope of this review, which is focused on the intrinsic security of the eBPF technology rather than its use for external security purposes. The second category has limited relevance, too. The third category, which investigates the security of eBPF, is the one of primary interest, as it deals with the vulnerabilities of the eBPF system and its components such as the verifier, JIT compiler, runtime, helper functions, maps, and attachment mechanisms. The papers in this category have been considered relevant. A structured spreadsheet was used to track the inclusion/exclusion of each paper, along with a short justification for the decision. After this refinement process, the final number of papers included in the SLR was 45. These selected works form the basis for the analyses and classifications presented in the following subsections. 5.4.3 Classification of the Scientific Papers and Contributions The literature that is relevant for this review reveals several recurring research directions that can be grouped into the following main classes. 1. Studies offering broad assessments of eBPF’s security posture, mapping out its potential attack surfaces. 2. Description of attack techniques that are based on exploiting specific vulnerabilities of the eBPF system, possibly in combination with other non-eBPF known vulnerabilities, to compromise the kernel security (DoS, sensitive data leakage, privilege escalation, etc.). In these papers, possible countermeasures are also presented. 3. Systematic approaches for identifying vulnerabilities, such as advanced fuzzing techniques to generate eBPF code that may trigger vulnerabilities of the eBPF system. 4. Techniques to strengthen eBPF’s resilience, either through software and hardware improvements—including memory isolation, runtime protections, and custom kernel modules—or through formal methods that aim to enforce correctness in critical parts of the pipeline. For the purpose of our study, the papers that belong to classes 1., 2., and 3. are used to identify the main threats, vulnerabilities, attack surfaces, and exploitation techniques that apply to the
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 67 - August 31, 2025 eBPF system, while the papers that belong to classes 2. and 4. are used to identify the main mitigation techniques for such threats. 5.4.4 Threats, Vulnerabilities, Attack Surfaces, and Exploitation Techniques From the analysis of the relevant literature, three main kinds of threats emerge: 1. An unprivileged user can exploit an eBPF vulnerability by loading malicious eBPF code crafted to harm the system (e.g., DoS), alter its operation, steal sensitive data, or escalate privileges. This class of threats occurs only on systems where unprivileged eBPF code loading is enabled, i.e., where unprivileged_bpf_disabled is set to 0. 2. A privileged or unprivileged user can be convinced to load eBPF code that contains malware. This can be achieved by an attacker in various ways, such as by registering the malicious code in public code repositories. If the user who is tricked into using the malware is privileged, this threat also affects a system where unprivileged BPF execution is disabled. 3. A privileged or unprivileged user can be convinced to load a container including eBPF code that contains malware. Even if the eBPF code runs inside the container, it has been shown that there are ways to escape the container borders and perform malicious actions on the entire system. As already mentioned, there is also another kind of malicious use of eBPF code documented in the literature. Specifically, this is the use of eBPF code by an attacker after having taken control of a host (maybe by exploiting non-eBPF vulnerabilities) to conceal malicious activities on the host, thereby making the attack stealthy. By performing a threat analysis, we identified an additional, theoretically possible, threat: an honest eBPF programmer could accidentally introduce a vulnerability in the eBPF code. This kind of vulnerability could be exploited by providing the eBPF program with malicious inputs. If the program execution is triggered by the arrival/processing of network packets via XDP/TC, network attackers could exploit the vulnerability by injecting malicious packets. If instead the program is attached to other local events, such as system calls, then the vulnerability could be exploited by calling the traced functions with malicious arguments. Although these scenarios are theoretically possible, they are not mentioned in the literature on eBPF security, probably since the presence of the eBPF verifier makes the accidental and undetected introduction of vulnerabilities in eBPF code quite unlikely. In Section 6.1.1, some further studies and considerations about this possibility are reported. Here, instead, we focus on the main threats listed above, which are all based on the intentional creation of malicious eBPF code. The different ways reported in the literature to create eBPF malware, i.e., code that may hurt the system or perform unauthorised operations, are illustrated in the rest of this section. Most of the exploited weaknesses are vulnerabilities existing in the different components of the eBPF system (verifier, JIT compiler, helper functions, etc.). After these vulnerabilities are discovered, patches are introduced to counter or mitigate them, usually before the vulnerabilities are made public. Exploitation of eBPF verifier bugs 141 : The eBPF verifier is a very complex piece of software, in which bugs may occur. The main way a bug in the verifier may introduce a vulnerability is if it may cause the verifier to incorrectly accept as valid a program that is invalid (and so unsafe 141 M. H. N. Mohamed, X. Wang, and B. Ravindran, “Understanding the security of linux ebpf subsystem”, in Proceedings of the 14th ACM SIGOPS Asia-Pacific Workshop on Systems, ser. APSys ’23. New York, NY, USA: Association for Computing Machinery, 2023, pp. 87–92. doi:10.1145/3609510.3609822
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 68 - August 31, 2025 or insecure to execute). By exploiting such a bug, an attacker can succeed in loading a malicious eBPF program that should not be loaded, with possibly serious security consequences. eBPF verifier bugs of this kind are continuously discovered and fixed, and are documented in the literature. Recently, the search for exploitable verifier bugs has been done more systematically, by means of dedicated fuzzers. Thanks to this technique, many more eBPF verifier bugs have been discovered and fixed. However, as the verifier is constantly evolving, new bugs may be introduced, and non-publicly known bugs may still exist. For completeness, there is also another kind of security vulnerability due to eBPF verifier bugs: the verifier’s code itself may contain a security vulnerability that can be triggered by trying to load malicious programs specifically crafted to stimulate it. Exploitation of eBPF JIT compiler bugs 142 : Some bugs of the eBPF JIT compiler have been exploited by crafting eBPF malicious programs that pass verification, but trigger the JIT vulnerabilities, causing kernel crash or even hijacking of the kernel control flow. Exploitation of eBPF helper functions: The eBPF helper functions are widely used in eBPF programs to perform operations that, while useful and necessary, could not be expressed under the strict programming constraints enforced by the verifier. These functions are assumed to be safe to execute by the verifier, which just makes a few checks on their arguments. Unfortunately, as documented by Jia et al., 143 the eBPF helper functions may have their own vulnerabilities that can be exploited by calling them in specific ways from malicious code. For example, the above-referenced paper showed that nested calls of the bpf_loop helper function could be used to create malicious eBPF programs that virtually do not terminate, and that specific helper functions can be used to crash the system by calling them with unexpected arguments that the verifier does not prohibit. Several vulnerabilities like these ones are continuously discovered and patched in the Linux kernel. As the number and complexity of eBPF helper functions is constantly growing, so is the number of introduced vulnerabilities. BPF program nesting 144 : As a specific issue related to the use of helper functions, while in each verified eBPF program the stack is capped to 512 bytes, the eBPF verifier does not properly check what may happen to the stack inside the called helper functions, posing a risk during eBPF execution. More precisely, what may happen is that another eBPF program is attached to function calls that occur inside a helper function. If this happens, this other eBPF program is executed nested inside the execution of the first one which called the helper function. As the verifier does not take these situations into account, such nested executions may cause the overflow of the kernel stack (the cap applies to each eBPF program, but when one is executed nested inside another one, the cap may be exceeded). Cross Container Attacks 145 : Various attacks for container escape have been shown to be possible when eBPF is used inside containers, since container isolation is limited when referring to eBPF. Most notably, He et al. pointed out that eBPF programs can trace processes in the entire system, not only those in the container, which can be exploited for escaping the containers 142 L. Nelson, J. V. Geffen, E. Torlak, and X. Wang, “Specification and verification in the field: Applying formal methods to BPF just-in-time compilers in the linux kernel,” in 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). Nov. 2020, pp. 41–61. Available: https://www.usenix.org/conference/osdi20/presentation/nelson 143 J. Jia, R. Sahu, A. Oswald, D. Williams, M. V. Le, and T. Xu, “Kernel extension verification is untenable,” in Proceedings of the 19th Workshop on Hot Topics in Operating Systems, ser. HOTOS ’23. New York, NY, USA: ACM, 2023, p. 150–157. doi:10.1145/3593856.3595892. 144 S. Chintamaneni, S. R. Somaraju, and D. Williams, “Unsafe kernel extension composition via bpf program nesting,” in Proceedings of the ACM SIGCOMM 2024 Workshop on EBPF and Kernel Extensions, pp. 65–67. doi:10.1145/3672197.3673440. 145 Y. He, R. Guo, Y. Xing, X. Che, K. Sun, Z. Liu, K. Xu, and Q. Li, “Cross container attacks: The bewildered eBPF on clouds,” in 32nd USENIX Security Symposium. Anaheim, CA, 2023, pp. 5971–5988. Available: https://www.usenix.org/conference/usenixsecurity23/presentation/he
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 69 - August 31, 2025 where they run. This can be done by employing some well-known offensive BPF helper calls that inherently allow for compromising the security of the system, especially in the context of containers, and by adopting strategies (documented in the paper) to circumvent the classical container isolation mechanisms. By means of these attacks, the eBPF code running in the container can attack processes outside the container with DoS attacks, sensitive data stealing, and process hijacking to execute malicious actions and take control of the external environment or of other containers. The risk is not negligible because a significant proportion of real containers enable eBPF even with the possibility of running offensive helper calls. EPF (Evil Packet Filter) 146 is an attack methodology that exploits the Linux kernel’s BPF infrastructure to inject malicious payloads that can be used to create exploits in combination with kernel memory corruption errors such as buffer overflows. Several techniques are used in the Linux kernel to make the exploitation of security vulnerabilities like buffer overflow impossible or very difficult (these techniques prevent user code/data from being executed/accessed freely by the kernel). The attacks shown in the paper bypass these protections by using alternative BPF-based payloads. The authors demonstrate how even unprivileged users can leverage such techniques to bypass existing kernel isolation techniques through two distinct attack instances: BPF-Reuse and BPF-ROP. They can be used to achieve privilege escalation. In particular, in the first one, they leveraged the usage of classic BPF, which is not forbidden for unprivileged users in popular distributions. They exploited existing vulnerabilities in the kernel to hijack execution flow onto the eBPF interpreter and, through spraying, leveraged specially crafted BPF programs containing encoded malicious instructions that are executed when the interpreter begins processing from a specific offset, abusing the BPF instruction format. The other attack instead aimed to create ROP chains using a third writing memory region. Speculative Execution Attacks 147 , 148 : These attacks, also known as transient execution attacks, exploit the speculative execution mechanisms found in modern processors. Such mechanisms guess the instructions that will be executed next, and transiently anticipate their execution to improve program execution performance, reverting the execution state in the (unlikely) case the guess was wrong. However, this kind of mechanism can also be exploited for leaking secrets through covert channels (e.g., the cache). The most common speculative execution attacks are the ones known as Spectre. As eBPF programs can be jit-compiled to native code, they can also be affected by these attacks, but such attacks have been shown to be possible in some cases even when the programs are interpreted. Several variants of Spectre have been found since the first one was discovered in 2017 and made public in 2018. The existence of so many variants is a challenge for protection. After the discovery of these attacks, some mitigation techniques have been introduced. However, the existing mitigations are not definitive solutions. 5.4.5 Mitigation Techniques In recent years, numerous attempts have been made to improve the security of the eBPF pipeline. The mitigation techniques documented in the literature are presented here, categorised according to their target. 146 D. Jin, V. Atlidakis, and V. P. Kemerlis, “EPF: Evil packet filter,” in 2023 USENIX Annual Technical Conference (USENIX ATC 23). Boston, MA: USENIX Association, Jul. 2023, pp. 735–751. Available: https://www.usenix.org/conference/atc23/presentation/jin 147 P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom, “Spectre attacks: Exploiting speculative execution,” in 2019 IEEE Symposium on Security and Privacy (SP), 2019, pp. 1–19. doi:10.1109/SP.2019.00002 148 O. Kirzner and A. Morrison, “An Analysis of Speculative Type Confusion Vulnerabilities in the Wild”, in 30th Usenix Security Symposium, 2021, pp. 2399-2416. Available: https://www.usenix.org/system/files/sec21-kirzner.pdf
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 70 - August 31, 2025 Memory isolation Several papers proposed the adoption of memory isolation techniques, such as Software Fault Isolation (SFI) or (usually platform-specific) hardware primitives, in addition to the static verifier checks. SafeBPF 149 is a proof-of-concept framework that secures eBPF memory accesses and jumps at runtime using an SFI technique and the ARM processors’ memory tagging extension. It extends the previous work, SandBPF, 150 that only relied on SFI to ensure memory safety. Memory isolation is enforced by applying bit-masks to restrict memory access to predefined areas, and kernel objects are mirrored in allocated memory when necessary. Control flow integrity is maintained via a hash map tracking execution positions and required capabilities. Despite adding runtime checks, the overhead remains under 10%. ARM memory tagging works by assigning tags to memory regions and verifying pointer integrity at the hardware level. The sandbox is divided into a shared map section and an internal program section, containing stack, heap, and mirrored kernel objects. MOAT 151 is a memory isolation framework for securing eBPF execution in the Linux kernel using Intel Protection Key Supervisor (PKS) and Process Context Identifier (PCI). It isolates global structures, stacks, maps, and runtime components while enforcing access control via PCIs. Helper function security is ensured through Dynamic Parameter Auditing, which checks inputs at runtime against verifier-calculated ranges, and Critical Object Protection, which blocks vulnerable kernel objects using PKS. MOAT prevents BPF memory-related CVEs with minimal overhead (1–4%), though tracing programs experience higher slowdowns (6–13%). Unlike SafeBPF/SandBPF, it actively restricts kernel object access rather than merely discouraging it. HIVE 152 aims to replace the eBPF verifier with runtime memory isolation and pointer authentication on AArch64, treating eBPF programs as userspace code to prevent direct kernel access. In particular, memory accesses to kernel memory trigger exceptions, which are handled with the actual access to the kernel memory and all the necessary checks, transparently managing safety-critical memory access. A description table prevents kernel pointer leaks, while additional isolation mechanisms concern maps, isolating their data from metadata, creating isolated stacks, and helper function parameters checks. DoS attacks are mitigated through timers and exception handling. HIVE successfully defends against tested CVEs, but remains vulnerable to EPF attacks on JIT-compiled code. Overhead varies significantly, reaching 124% for short executions, but averaging around 5% for long-running programs, practically bypassing the need for a verifier and improving the security of the eBPF program execution. 149 S. Y. Lim, T. Prasad, X. Han, and T. Pasquier, “Safebpf: Hardware-assisted defense-in-depth for ebpf kernel extensions,” in Cloud Computing Security Workshop (CCSW). New York, NY, USA: ACM, 2024, pp.80–94. doi:10.1145/3689938.3694781. 150 S. Y. Lim, X. Han, and T. Pasquier, “Unleashing unprivileged ebpf potential with dynamic sandboxing,” in 1st Workshop on EBPF and Kernel Extensions (eBPF ’23). New York, NY, USA: ACM, 2023, pp. 42–48. doi:10.1145/3609021.3609301. 151 H. Lu, S. Wang, Y. Wu, W. He, and F. Zhang, “MOAT: Towards safe BPF kernel extension,” in 33rd USENIX Security Symposium (USENIX Security). Philadelphia, PA: USENIX Association, Aug. 2024, pp. 1153–1170. Available: https://www.usenix.org/conference/ usenixsecurity24/presentation/lu-hongyi 152 P. Zhang, C. Wu, X. Meng, Y. Zhang, M. Peng, S. Zhang, B. Hu, M. Xie, Y. Lai, Y. Kang, and Z. Wang, “Hive: a hardwareassisted isolated execution environment for ebpf on aarch64,” in 33rd USENIX Security Symposium, USENIX Association, 2024, pp. 163-180. Available https://www.usenix.org/system/files/usenixsecurity24-zhang-peihua.pdf.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 71 - August 31, 2025 KMO 153 is a security mechanism that detects illegal kernel virtual memory modifications to prevent privilege escalation attacks, that is not specific to eBPF. It creates a secret virtual memory to monitor the original kernel memory while ensuring isolation from corruption. KMO inspects system call arguments, prevents malicious injections, and protects direct mapping by forcibly unmapping memory regions. It employs virtual memory switching patterns to enhance monitoring. Tested on eBPF kernel vulnerabilities, KMO effectively detects memory corruption with minimal overhead. Its approach strengthens kernel security by preventing unauthorised modifications. Protection from transient execution attacks While numerous attempts have been made by CPU designers to offer protection against transient execution attacks, many of them are left to be covered by the compilers and software developers rather than directly mitigating them on the CPUs. The eBPF community responded to these attacks by adding additional checks in the verifier for non-takeable branches, and memory barriers to avoid speculation. However, this approach made the verifier much more selective, leading to a much higher program rejection rate. For this reason, the maintainers decided to leave these checks only for the unprivileged mode, resulting in the majority of eBPF programs requiring super user permission, since the acceptance rate of the verifier becomes much higher this way. In the literature, several other studies have been made about techniques to improve the protection against transient execution attacks. VeriFence 154 is a tool developed to mitigate Spectre-related transient side-channel attacks in eBPF by inserting memory barriers where the verifier detects potential vulnerabilities. This technique allows unprivileged programs, often rejected due to the above-mentioned Spectre defences, to pass verification with minimal overhead. A database analysis showed that only 31% of the most common eBPF applications could run unprivileged with the eBPF verifier filter, while VeriFence reduced rejection to 4%. The tool limits branch prediction risks by enforcing architecture-specific barriers (e.g., lfence for x86 64). However, it does not address other Spectre attacks, as the kernel remains vulnerable and relies on administrators to manage security risks. Another mitigation technique against transient execution attacks is BeeBox. 155 It introduces the beebox, an isolated memory region containing runtime data such as stack, context, and maps, ensuring unprivileged programs cannot compromise the kernel. Memory safety is enforced using SFI, inserting BPF BOXMEM instructions before memory accesses, which the JIT translates into safe address computations using the reserved register R12. Beebox also introduced the concept of clean pointers, which are pointers that are not affected by the program input, to prevent unsafe memory access in helper functions. Additional optimisations, like reduced context copying, further improve efficiency. BeeBox achieves strong isolation with a 20% overhead in macrobenchmarks, but maintains less than 1% degradation in real-world use cases like seccomp-BPF and packet filtering. 153 H. Kuzuno and T. Yamauchi, “KMO: Kernel memory observer to identify memory corruption by secret inspection mechanism,” in Information Security Practice and Experience, S.-H. Heng and J. Lopez, Eds. Cham: Springer International Publishing, 2019, pp. 75–94. 154 L. Gerhorst, H. Herzog, P. Wagemann, M. Ott, R. Kapitza, and T. Honig, “Verifence: Lightweight and precise spectre defenses for untrusted linux kernel extensions,” in 27th Int. Symp. on Research in Attacks, Intrusions and Defenses (RAID). New York, NY, USA: ACM, 2024, pp. 644–659. doi:10.1145/3678890.3678907. 155 D. Jin, A. J. Gaidis, and V. P. Kemerlis, “BeeBox: Hardening BPF against transient execution attacks,” in 33rd USENIX Security Symposium (USENIX Security). Philadelphia, PA: USENIX Association, Aug. 2024, pp. 613–630. Available: https://www.usenix.org/conference/usenixsecurity24/presentation/jin-di
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 72 - August 31, 2025 Protection from container escaping attacks A few relevant articles have shown how to enforce access policies with the addition of tools designed for container monitoring. Hyperbee 156 is a tool that audits eBPF system calls in guest VMs and enforces security checks. It modifies the kernel to invoke a guest application via virtio whenever the bpf() syscall is made. The tool provides four verification methods: the primary eBPF verifier, a customisable security verifier using DFAs, a signature verifier for signed programs, and a code verifier based on past malware. Runtime overhead is negligible, but verification can impact performance, especially when using DFA checks. eBPF-sec 157 is a defence framework that protects containers from eBPF attacks. It operates in two phases: in the Dynamic Monitoring Phase, while the eBPF programs are executed normally, it tracks bpf system calls, specifically the bpf_cmd value associated with it, and the hashes of executed eBPF code. In the Restriction Phase, it blocks bpf system calls with bpf_cmd values not registered during monitoring, as well as programs with hashes that differ from those recorded. This enhances the security of eBPF-enabled containers, preventing attacks while allowing legitimate eBPF usage with minimal performance overhead. It was built upon libbpf, allowing it to be easily integrated. Strengthening the eBPF pipeline through formal methods Some authors attempted to formally verify the various components of the eBPF pipeline considering the numerous vulnerabilities that are being found in them, and the fact that the current Linux eBPF verifier, the most important module to enforce security policies on eBPF programs, is currently not formally verified. Some authors proposed to replace the eBPF verifier with other verifiers developed with a more formal approach, with PREVAIL 158159 being the most notable example. Others proposed additional verifiers, such as BpfVerify, 160 which performs automatic bit and memory level verification of eBPF code by translating eBPF programs into Constraint Horn Clauses (CHC) over bitvectors and arrays, allowing to verify functional properties by means of a SAT solver. It has been shown to be quite effective in checking properties like memory safety and absence of overflows. Other authors focused on the formal verification of Jit compilation, and, specifically, in the development of formally verified Jit compilers. 161 5.4.6 Security of Hardware Platforms Modern eBPF offers powerful in‑kernel programmability for system monitoring, network processing, and more—yet its deep integration with the operating system also introduces 156 Y. Wang, D. Li, and L. Chen, “Seeing the invisible: Auditing ebpf programs in hypervisor with hyperbee,” in 1st Workshop on EBPF and Kernel Extensions (eBPF ’23). New York, NY, USA: ACM, 2023, pp. 28–34. doi:10.1145/3609021.3609305. 157 K. Xu, X. Wang, L. Li, and J. Gao, “ebpf-sec: A defensive framework against ebpf attacks on containers,” in 2024 IEEE Symposium on Computers and Communications (ISCC), 2024, pp. 1–7. doi:10.1109/ISCC61673.2024.10733575. 158 E. Gershuni, N. Amit, A. Gurfinkel, N. Narodytska, J. A. Navas, N. Rinetzky, L. Ryzhyk, and M. Sagiv, “Simple and precise static analysis of untrusted linux kernel extensions,” in 40th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). New York, NY, USA:ACM, 2019, p. 1069–1084. doi:10.1145/3314221.3314590. 159 G. Jin, J. Li, and G. Briskin, “Research report: Enhanced ebpf verification and ebpf-based runtime safety protection,” in IEEE Security and Privacy Workshops (SPW), 2024, pp. 224–230. doi:10.1109/SPW63631.2024.00026. 160 M. Bromberger, S. Schwarz, and C. Weidenbach, “Automatic Bitand Memory-Precise Verification of eBPF Code,” in 25th Conference on Logic for Programming, Artificial Intelligence and Reasoning. EPiC Series in Computing, vol. 100, Port Louis, Mauritius, May 2024, pp. 198–221. doi:10.29007/sj4l. 161 L. Nelson, J. V. Geffen, E. Torlak, and X. Wang, “Specification and verification in the field: Applying formal methods to BPF just-in-time compilers in the linux kernel,” in 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, Nov. 2020, pp. 41–61. Available: https://www.usenix.org/conference/osdi20/presentation/nelson
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 73 - August 31, 2025 serious security risks, including bypasses of the verifier, privilege escalation, and potential kernel-level exploits. To mitigate these vulnerabilities, recent research has focused on hardware-enforced security mechanisms that strengthen execution guarantees and reduce eBPF’s attack surface. Key directions include Trusted Execution Environments, Memory Tagging Extensions (MTE), Intel’s Control-flow Enforcement Technology (CET), Performance Monitoring Units (PMUs), Intel’s Protection Keys (PKS/MPK), and Hardwareenforced Virtualisation. A Trusted Execution Environment is a hardware-based security mechanism integrated into modern CPUs (and potentially GPUs), providing an isolated execution environment to protect code and data during runtime. TEEs address a critical gap in the data protection lifecycle by safeguarding data in use, complementing traditional methods for securing data at rest (e.g., disk encryption) and in transit (e.g., TLS). TEEs enforce isolation through hardware-rooted mechanisms such as memory encryption and restricted access controls. Memory regions assigned to a TEE are encrypted and can only be accessed by code executing within the TEE context. This ensures that even privileged software layers—such as the operating system, hypervisor, or container runtime—cannot observe or tamper with TEE-protected memory, even if compromised. According to the Confidential Computing Consortium, TEEs must guarantee three core properties: data confidentiality, data integrity, and code integrity. One of the major security advantages of TEEs is a reduced Trusted Computing Base (TCB). By assuming the host environment is untrusted, TEEs shift trust primarily to the processor and its firmware, minimising reliance on complex and potentially vulnerable system software. To establish trust externally, TEEs support remote attestation, wherein the platform generates cryptographic proof (e.g., signed hashes of the code and data) that can be verified by a remote party, ensuring that only approved workloads run within a genuine TEE. TEE architectures vary by design. Process-based TEEs like Intel SGX isolate selected userspace code regions and require application-level integration. In contrast, VM-based TEEs, such as AMD SEV-SNP and Intel TDX, protect entire virtual machines, enabling execution of unmodified OSes and applications. Other implementations include Arm TrustZone, Arm CCA Realms, IBM PEF, and RISC-V PMP. Cross-platform projects like Enarx aim to abstract these differences, offering a unified runtime (e.g., for WebAssembly) that runs securely across various TEE hardware. Next, the Memory Tagging Extension is a hardware-assisted security feature introduced in ARM architectures to enhance memory safety by detecting common memory errors such as use-after-free, out-of-bounds accesses, and buffer overflows. By associating metadata (tags) with memory allocations and validating them at runtime, MTE enables efficient, low-overhead detection of memory violations, supporting use cases like debugging, fuzzing, and security hardening—particularly in modern systems such as Android and embedded platforms. In this context, Unterguggenberger et al. 162 introduced Multi-Tag, a hardware-software codesign that implements multi-granular tagging at both object and page levels, thereby improving resilience against both spatial and temporal memory safety violations. Similarly, CoMeT 163 extends the MTE model through the introduction of a Tag Permission Configuration Register (TPCR), allowing fine-grained enforcement of read/write permissions per tag. A 162 Unterguggenberger, Martin, et al. "Multi-tag: A hardware-software co-design for memory safety based on multi-granular memory tagging." Proceedings of the 2023 ACM Asia Conference on Computer and Communications Security. 2023. 163 Lee, Jinjae, et al. "CoMeT: Configurable Tagged Memory Extension." Sensors 21.22 (2021): 7771.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 80 - August 31, 2025 bytecode entities, such as registers, enum values, and offsets, rather than to the original C code entities. Although logs may include original source statements as references, mapping low-level verifier messages back to high-level constructs (e.g., C variables, data structures, and helper calls) remains a manual, error-prone process. Another related difficulty for the programmer is that finding a fix for an issue reported by the verifier is often not immediate, especially for inexperienced programmers. All these difficulties make eBPF programming quite error-prone and time-consuming. Especially with modern Continuous Integration (CI) pipelines and rapid development cycles, having to wait for long manual diagnosis of verifier failures can introduce significant delays. One last aspect to be considered is that the bugs that are continuously discovered in the eBPF verifier are witnessing its limitations as a means to prevent all potential security vulnerabilities that may be introduced in eBPF code. For this reason, extra checks may be necessary to achieve code with the highest security guarantees. All these aspects motivated the ELASTIC initiative of developing a static C code analyser capable of reporting at least the same issues found by the eBPF verifier, but with precise and easy-to-understand error messages related to the original C source code, together with actionable suggestions to fix the found issues. The availability of such a tool can obviously improve the developers’ experience and productivity when developing eBPF code, in addition to improving eBPF code security. 6.1.2.2 Requirements The requirements for the static eBPF code security analyser mainly come from KPI 1.2: “Release of a proof-of-concept static analyser for eBPF source code, detecting and reporting over 80% of security issues identified by the bytecode verifier with precise source code references and informative messages” and are detailed below: 1. The analyser must accept C code as accepted by the Clang compiler. This requirement is motivated by the fact that the most common way of developing eBPF code is based on writing C code, which is compiled with the Clang compiler. 2. The analyser must be able to detect and report over 80% of the security issues identified by the eBPF bytecode verifier and possibly even some of the issues that the verifier fails to report. As a reference, we decided to use the verifier of kernel versions 6.X, and in particular, the LTS one. 3. Security issues must be reported by the verifier with precise source code references (at least the filename and line number). 4. Security issues must be reported by the verifier with precise and easy-to-understand informative messages. 5. Precise fix suggestions should be provided by the analyser for each reported security issue. The verifier should not introduce excessive latency. The time taken to produce its output must be comparable to the normal compilation/loading times. This requirement is necessary to enable a fluent development process.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 81 - August 31, 2025 6.1.2.3 State of the Art, Methodology, and Design Recently, some attempts have been made to improve the eBPF development process, but they go in different directions and address different issues and difficulties encountered by programmers in developing eBPF programs. Most notably, they propose an approach based on code reuse and modularity which can simplify the development of eBPF code. The problem we are addressing with the static eBPF code security analyser is very much orthogonal to this. The methodology followed to design the analyser is based on a preliminary deep study of the eBPF verifier to determine its detection and reporting capabilities, and to classify the securityrelated errors it can raise. This is also useful in order to have a reference for the evaluation of KPI 1.2. This preliminary study took considerable effort because of the increased complexity of the verifier code, which now exceeds 20K lines. The study revealed an increased coverage of security vulnerabilities in the latest versions of the verifier, driven by the numerous eBPF-related vulnerabilities that were recently discovered. This improvement was paired with improved reporting capabilities of the verifier: in the latest versions, the verifier can also output the source code lines the error refers to if the code was compiled with the debug option. However, no file name and no line number are given, but only the string of the line. Moreover, the explanations remain unclear and refer to bytecode entities only. In order to identify and classify the errors the verifier can detect, the output statements in the verifier code were analysed systematically. The results are shown in Table 5. Table 5: Classification of output messages in the eBPF verifier code Category Count Log messages 54 Internal errors 97 Bytecode errors 123 Other errors 176 Relevant errors 79 Total 529 Out of the 529 possible messages the verifier can output, only 79 are relevant for our study. The 54 log messages are not relevant as they are not error messages. The 97 internal errors are also not relevant because they refer to internal issues in the eBPF verifier code itself (e.g., reaching states that, at the time of design, were considered impossible) rather than issues in the analysed code. The 123 bytecode errors are errors affecting the input code, and hence, they may represent code security vulnerabilities, but they cannot be generated by compiling C code, and this is the reason why they are not considered relevant. More precisely, bytecode errors may be introduced exclusively by writing incorrect eBPF bytecode manually or when the compiler generates invalid eBPF bytecode, which should never occur. Finally, the 176 other errors include several types of errors that either do not depend on the input code, such as for example the absence of the privileges necessary to load/run the input code or errors related to BTF (BPF Type Format), and a set of extremely rare errors for which almost no documentation exists (a Google search for them results in just a few references, most of which point to the kernel pull request that introduced the message). This last part of the class is also considered irrelevant (although in principle it might contain errors that depend on the input code) due to the difficulty of
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 82 - August 31, 2025 understanding their nature and because of their extremely low probability of occurrence. They are left for further study. The 79 relevant errors are the ones representing real issues of the input code that may affect the original C code and that may be fixed by acting on the C code. They are also the errors that our analyser should manage. Two possible approaches, shown in Figure 10, have been identified to build the analyser. Figure 10. The two approaches considered for the design of the analyser. The first one, shown in the upper part of the figure, consists of building a C code analyser that exploits the Clang static analysis framework. The second one, shown in the lower part of the figure, consists of building a tool that we call Pretty Verifier, which reads the output of the eBPF verifier and enriches it with additional information about the root cause of the raised errors and the required information (i.e., precise references to the source code, easy-tounderstand diagnostic messages, and fix suggestions), built by also analysing the original source code. Each approach has its own pros and cons. The pro of the first approach is that it can be used to detect dangerous code that would not be blocked by the eBPF verifier. On the other hand, its cons are that (i) it is very difficult to fully match the complexity and depth of the eBPF verifier’s checks at the source level, (ii) it can lead to false positives and false negatives because of the differences between C and eBPF bytecode, and (iii) its performance may not be compatible with our requirements. Instead, the pros of the second approach are that (i) it should not raise false positives other than the one raised by the verifier (because there would be a single source of truth), (ii) in principle it can manage all the errors raised by the verifier, (iii) it is simpler and more performant than the other solution, and (iv) it could be adapted to work with other languages such as Rust. The cons of the second approach are that it is closely tied to kernel/verifier changes and that it cannot be used as a security against not yet patched eBPF verifier vulnerabilities. After careful evaluation of such pros and cons, we decided to opt for the second approach, but kept the possibility of combining it with a Clang-based static C code analysis, which would mitigate at least its second con.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 83 - August 31, 2025 6.1.2.4 Implementation A first development iteration led to the implementation of the Pretty Verifier module, which is the core of the analyser. With this implementation, it was also possible to start the testing phase. The Pretty Verifier includes a parser for the raw log stream produced by the eBPF verifier, which is based on regular expressions tuned to the 79 managed messages that were found to be relevant in our previous analysis. This regex-based approach is extremely fast, but also flexible and extensible: new error types can be added to keep pace with new verifier versions by simply defining additional regex patterns. For each one of the 79 managed messages, a thorough analysis has been made by searching for its occurrences in eBPF developer discussions and related forums. This analysis was the basis for building the specific error handler. This handler includes an additional error explanation template for the error message, which aims not only to explain the meaning of the error but also to connect the error to the C source code counterpart and ease the debugging process, including specific additional information. This additional information is extracted from the C source code and from the llvm object code. Moreover, bytecode-related information such as registers and enums is translated into their equivalent C pointers and variables. For instance, Pretty Verifier translates the type of a BPF register into a descriptive format, leveraging the reg_type enumeration from the bpf.h file in the kernel sources. The enhanced logs also include more explanations for checks performed by the verifier, derived from comments in the eBPF verifier source code and references to online forums that discuss common pitfalls and their resolutions. For example, when a division is performed on a pointer, the eBPF verifier just outputs the message “pointer arithmetic with /= operator prohibited”. However, as only additions and subtractions are allowed, Pretty Verifier provides this information in the enhanced error message, giving the developer the precise verification criteria. Specific error types receive tailored enhancements to further help developers. For example, when the eBPF verifier detects that a register’s type does not align with a helper function’s expected signature, the tool identifies the relative variable in the original C code. Similarly, for one of the most important security vulnerabilities in C code, i.e., invalid memory accesses due to variables that have not been correctly bound checked before and that can lead to an exploitable buffer overflow, the tool calculates the correct size required for the bound check and highlights it in the output. The error explanation template, instantiated with the above-mentioned additional information, is completed with other information: the precise error location in the C source code (line number and file name of the C source file where the error occurred), additional details for certain error messages that require more context, and fix suggestions. Figure 11 shows examples of the output messages generated by Pretty Verifier for some of the above-mentioned cases. The Pretty Verifier code is publicly available in the GitHub repository. 169 169 https://github.com/netgroup-polito/pretty-verifier
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 84 - August 31, 2025 Figure 11. Examples of output of the Pretty Verifier analyser. 6.1.2.5 Testing Numerous tests have already been created to validate the reliability and effectiveness of Pretty Verifier, but the development of tests is not yet finished. The final version and final results will be reported in D1.2. A first test suite was created with the ideal goal of testing the behaviour of the tool for all the managed verifier errors, checking that precise and easy-to-understand informative messages and correct fix suggestions are reported by the tool under the several main different conditions in which the errors may occur. Although existing sources with faulty eBPF programs—such as Liz Rice’s “Learning eBPF” GitHub repository and an Anteon blog post—offered useful starting points, they covered only a fraction of the error messages handled by the tool. Consequently, additional eBPF C code test cases with intentional faults were written with the aim of exercising every implemented handler. The current status is that, overall, using a mix of community examples and newly developed test cases, it was possible to trigger 17 distinct verifier error messages out of the 79 such messages. Multiple variants of the test cases were produced for each of these verifier errors to achieve good coverage across the different possible reproducible scenarios. However, we could not yet find any test case to trigger the other 62 verifier errors previously identified as potentially related to the original source code. Further study will be done to get a more precise understanding of them and to look for possible ways of generating them. The final findings will be reported in D1.2. It is important to remark that, although 17 verifier errors out of 79 may seem like a poor coverage, the currently managed verifier errors represent the most typical issues encountered
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 85 - August 31, 2025 in eBPF development, some of them including several different error sub cases. But, most importantly, they represent the majority of the errors occurring in online forums like Stack Overflow: the majority of the verifier errors that could not be triggered by our tests could not be found when searching for them in Stack Overflow or similar forums. So, the current coverage can already be considered quite significant for practical purposes. Below is the list of the 17 verifier errors covered so far. • Invalid pointer operations: includes the use of bitwise (&, |, ^) and arithmetic operators (division, modulo, multiplication, left/right shift) on pointers. • Invalid access to BPF context: covers illegal access to fields in unsupported program types, such as socket structures or sk_msg contexts. • Invalid memory access (like writing using a scalar as a pointer). • Invalid read of the stack. • Invalid spill of a register into the stack. • Accessing maps without proper upper bound check. • Accessing maps without proper lower bound check. • Accessing pointers with offset out of maximum bound. • Accessing packet using offset outside its data structure. • Missing GPL declaration for helper functions. • Missing GPL declaration for kernel functions. • Use of unknown or unsupported helper function. • Infinite loop detection. • Subtracting a pointer from a scalar, which is not allowed. • Type mismatch in helper function arguments. • Unreleased reference: reference to a resource (typically a ring buffer) is not released before returning. • Register R0 not initialised before returning. To further broaden the testing of the capability of precisely reporting the error location, an automated test-case-generation utility was also developed. It randomly alters source files—e.g., by adding blank lines or inserting bpf_kprint calls—so that the same logical error appears on shifting line numbers. These tests never failed. Another kind of test for a similar purpose was created to test multi-file programs, which gave good results, but with some failures: complicating the control-flows of the test cases, especially in the occurrence of two similar branches, debug information occasionally led the tool to report incorrect source lines. To resolve this issue, a dedicated “full mode” was introduced. It allows to generate the Pretty Verifier output by automatically compiling the input program with no optimisation. As optimisation is in many cases responsible for these failures, excluding it solves some of the failures. Even though it is not always a definitive solution, since the non-optimised code might differ from the optimised one, it proved helpful to understand the origin of the error more clearly in edge cases where debug information becomes unreliable. This mode serves as a useful fallback when precise line tracking is needed, and the standard pipeline is insufficient. After removing the error, the tool can be run again in normal mode (i.e., with optimisation enabled). 6.1.3 eBPF-based IDS (EO-KPI-9) This section provides a preliminary description of a novel Intrusion Detection System (IDS) currently being developed within the ELASTIC project. Unlike other established and open-
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 86 - August 31, 2025 source offerings, this IDS stands out thanks to its use of eBPF and FPGA technologies, which grant both excellent compatibility and integration with the Linux network stack, as well as hardware-accelerated traffic analysis for improved performance. The following subsections delve into both of these aspects of the project. 6.1.3.1 eBPF-based Traffic Capture The proposed IDS solution uses an innovative eBPF-based traffic capture tool to intercept outbound traffic generated by local applications. Compared to traditional capture technology based off of Linux’s pcap infrastructure (i.e., making use of raw AF_PACKET sockets and BPF filters through the libpcap library), our contribution aims to improve capture performance and reduce system overhead during active capture sessions, as well as retain information about the originating user and process while seamlessly supporting the interception of traffic before it is encrypted by an infrastructure proxy for service mesh communication. Additionally, eBPF allows us to move the capture function higher in the network stack, hence making it possible to acquire transport layer messages before packetization. This has the important advantage of reducing per-packet overhead and thus improving efficiency. A schematic representation of the difference between the two capture modes is provided in Figure 12. How traditional packet capture works. The Linux kernel offers explicit support for the traffic capture use-case; this is what powers libraries such as libpcap and, by extension, tools like tcpdump 170 and Wireshark. 171 Specifically, a packet capture session is bound to one (physical or virtual) network interface, such that all packets flowing through that interface are cloned and pushed up the stack towards the capture application. This includes both inbound and outbound network frames. When an interface is set-up for capture, a “tap” is installed in its low-level receive and transmit routines. In the transmission (TX) direction, this means that taps are encountered after all protocol layers are run and when the packet is fully formed and ready for transmission. While this is ideal for extracting low-level system information from the network (like Medium Access Control – MAC – addresses), it often results in additional overhead due to the inflated size of each captured packet, which could be inconvenient if such information is not needed, especially given that this metadata can generally be extracted from the static interface configuration. When a packet goes through a network tap, a BPF filter 172 (not to be confused with eBPF programs) is run (if present) to determine whether the packet must be captured or not. In case of positive output, the packet is cloned and appended to a kernel-side socket buffer. Asynchronously, the capture application can fetch packets (generally through the invocation of dedicated system calls) via reading from an AF_PACKET socket. 170 “Tcpdump and Libpcap.” https://www.tcpdump.org/ (accessed Jun. 13, 2025). 171 “Wireshark: The world’s leading network protocol analyzer.” https://www.wireshark.org/ (accessed Jun. 13, 2025). 172 The original Berkeley Packet Filter – nowadays also often referred to as classic BPF (cBPF) – is the formal precursor to the modern eBPF. First introduced in 1992 and currently supported by most major operating systems, cBPF can perform simple packet filtering in the Linux network tap subsystem, most commonly used for traffic capture. Nowadays, Linux maintains the traditional BPF user interface, though filters installed through it are automatically converted to eBPF.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 87 - August 31, 2025 Figure 12. Schematic representation of both the traditional and eBPF-powered traffic capture for outbound network traffic. Note how the eBPF capture is able to intercept the message higher in the network stack, thus relaying L4 messages rather than Ethernet frames. Design of the eBPF capture tool. A crucial design choice that determines the behaviour, performance, and compatibility of the capture tool is the type of eBPF probe used as its foundation. Specifically, two main options are applicable for this use-case: 1. Relying on eBPF kernel tracing and observability primitives. As presented in the general introduction to eBPF in Linux, one of the main strengths of its current state is that it not only enables great control and programmability of the LKNS, it also unlocks powerful observability opportunities thanks to several eBPF program types which attach to many varied in-kernel events. Among these, tracepoints, kprobes, and fentry/fexit program types are some of the most commonly used for the purpose of monitoring and traceability, thanks to their ability to respond to the execution of most of the functions making up the kernel’s source code. This opens up the possibility to use this infrastructure to attach eBPF probes to the network stack’s layer-4 transmission code, in order to be “notified” whenever processes on the system were to output data over a transport-level socket. 2. Relying on eBPF networking primitives. Alternatively, network-specific eBPF infrastructure could also be used to intercept application-generated outbound traffic, though in order to respect our goal of lifting the capture to high-level L4 messages, packet-layer eBPF hook points such as TC egress cannot be considered. Instead, Linux offers extensive socket-layer eBPF support, capable of attaching (and controlling) to most events involving sockets. For this specific use-case, the
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 88 - August 31, 2025 BPF_PROG_TYPE_SK_MSG program type was contemplated. SK_MSG probes attach to a set of user provided sockets and respond to transmission events performed on them. Notably, any form of transmission would trigger the execution of linked SK_MSG eBPF programs, including traditional writes as well as sendfiles, which follow different paths in the LKNS’s transmit pipeline. When a SK_MSG program is invoked in response to a socket transmission event, the entire contents of the (linearised) user message are accessible to the eBPF sandbox, and could thus be cloned and lifted to the user-space for traffic capture. Overall, the second approach based on networking-specific hook points presents some key advantages: • Better support across kernel versions: an inherent limitation of eBPF tracing programs is that they link to the unstable function and struct definitions of the Linux kernel, which are subject to change across versions. By contrast, special purpose networking hooks behave like a public API and can thus rely on longer stability guarantees. • More streamlined interface to a wider set of functionalities: an SK_MSG capture solution can be easily architected to support both TCP and UDP sockets, as well as intercept both outbound and inbound (via its sibling BPF_PROG_TYPE_SK_SKB program type) traffic. Tools using the eBPF observability infrastructure would require a larger effort to achieve a similar feature set. Despite this, our eBPF traffic capture tool is currently following the model making use of eBPF’s tracing capabilities. Ultimately, in fact, an early prototype based on the SK_MSG technique was deemed unsuitable for the eventual integration with the IDS platform for two crucial reasons: 1. Stringent Linux version requirement. Due to a kernel bug that was discovered during development, the oldest version of Linux compatible with the capture tool would have been 6.4.7. This version was too recent for the deployment to the FPGA system where the IDS would be running. 2. Disappointing performance. More importantly, the SK_MSG infrastructure was found to deliver unsatisfactory levels of performance when used to intercept all application traffic. Specifically, TCP sockets connected to remote destinations would suffer large throughput reductions just by having an SK_MSG eBPF program attached. The likely cause of this phenomenon is the high cost of the message copy performed by the kernel prior to invoking the eBPF program in order to linearise the sent message; this additional copy is not required when using observability hooks. Additionally, since intra-node connection sockets are not affected by this problem, it is possible that TCP backpressure issues could also be playing a role. Due to these problems, revisiting the SK_MSG capture implementation is left as a possible future work while the kernel support for this feature matures. Instead, our eBPF capture tool is built around a central fentry 173 eBPF program attached to the tcp_sendmsg kernel function, which represents the TCP-specific implementation of the generic socket sendmsg operation. The probe performs a byte-level copy of the (possibly fragmented) message data and 173 Similarly to kprobes, fentry programs can attach to arbitrary kernel functions, though they boast lower invocation overhead.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 89 - August 31, 2025 places it in a ringbuffer map. 174 The userspace component of the capture tool is a Rust library which continuously epolls the map’s file descriptor for readability; upon a positive output from the epoll system call, the ringbuffer map is drained and all contained messages are served to the library’s user. It must be noted that, in case the lowest possible capture latency is desired, a busy polling solution could be developed in place of the current epoll mechanism. Further details on the eBPF capture tool, as well as extensive performance and capability considerations will be shared in D1.2. 6.1.3.2 Hardware AI-based IDS solutions Modern traffic capture systems focus on accurate, rapid, and adaptive intrusion detection capabilities. This section presents the ELASTIC security defence framework, which is engineered to identify and generate alerts for malicious behaviours or breaches of predefined policies within the low-level kernel activities monitored by eBPF-based traffic capture mechanisms. These activities include system calls, instruction execution, memory operations, and inter-process communication. Due to the high sensitivity of the captured data, its handling needs to take place with stringent safeguards to mitigate risks of data leakage, integrity violations, or unauthorised access. The ELASTIC IDS is an innovative hardware-accelerated solution that integrates two principal features: the performance advantages inherent to hardware implementation and the robust threat detection capabilities of artificial intelligence. Designed to address both current and emerging cybersecurity threats—including those previously unknown—the ELASTIC AI-IDS system combines hardware-based monitoring with advanced AI-driven security mechanisms. Key functionalities of this system include: (i) real-time data processing for immediate threat response, (ii) predictive analytics to anticipate and counteract evolving attack vectors, and (iii) high-accuracy detection of intrusion attempts, thereby enhancing the overall effectiveness of modern traffic monitoring infrastructures. The AI-driven hardware tool comprises two interdependent components that collectively enable its comprehensive functionality. The first component is a hardware-based IDS, based on Snort 175 —one of the most extensively utilised tools in network security. This component is mapped on a high-performance server equipped with a Xilinx Alveo U200 FPGA card 176 , where the corresponding accelerator is mapped (see Figure 13), focusing on the performance over ELASTIC network security tasks. Specifically, the system features a software interface operating on the host server, which is responsible for relaying traffic data requiring inspection to the hardware platform. The hardware component implements a highly parallelised, hardwareefficient pattern matching architecture 177 , 178 , where independent modules concurrently analyse distinct segments of eBPF-derived data. Upon detecting a match between the incoming data and preloaded signature patterns stored on the FPGA, the system generates an alert. This alert, along with the associated data, is transmitted back to the software layer, which subsequently 174 “‘BPF_MAP_TYPE_RINGBUF’ map type - eBPF Docs,” Ebpf.io, 2025. https://docs.ebpf.io/linux/maptype/BPF_MAP_TYPE_RINGBUF/ (accessed Jun. 24, 2025). 175 Roesch, Martin. "Snort: Lightweight intrusion detection for networks." Lisa. Vol. 99. No. 1. 1999. 176 AMD/Xilinx, AMD Alveo™ Data Center Accelerator Cards Product Brief (U200 | U250). San Jose, CA: AMD, 2023. [Online]. Available: https://www.xilinx.com/publications/product-briefs/alveo-product-brief.pdf 177 Deyannis D., et al. "The diversification and enhancement of an ids scheme for the cybersecurity needs of modern supply chains." Electronics 11.13 (2022): 1944. 178 Papadogiannaki E., et al. "A reconfigurable IDS framework for encrypted and non-encrypted network data in supply chains." 2023 International Conference on Engineering and Emerging Technologies (ICEET). IEEE, 2023.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 96 - August 31, 2025 with a 10-core virtual machine on faster Xeon(R) CPUE5-2670 2.30GHz processors and increased cache sizes. On the low level, closer to native, performance (through latency and cache misses metrics) scaling with the increasing of eBPF map size, program length, and the number of allocated CPU cores is evaluated, with noted trade-offs and specific dependencies between types of maps used, threshold cache size, and extra complexity factors affecting the distribution of workload over multiple CPU cores. More elaborated benchmarking and understanding, particularly of access overhead and performance related to the usage of different eBPF map types, and factors affecting it, are presented in the paper by Liu et al. 192 Still relatively little overall attention has been dedicated to these issues by now, expected to grow significantly with the spread of production-level solutions in 6G application scenarios.181 With the development and availability of different emerging and maturing eBPF verifiers additional to the core in-kernel ones (mentioned in Section 5.4.5 above), their comparative performance and evaluation benchmarking is also being explored. Recent initial efforts for PREVAIL versus in-kernel versions, 193 and analyses of the key safety and security features and vulnerabilities of the verifier, extend also to practical performance-affecting issues like buffer overflows or ALU range-tracking errors. 194 Finally, some emerging efforts in deployment performance monitoring/tracking explore the direction of auditing of registered eBPF observability and performance overhead metrics values on the directly coupled DLT layer, like blockchain. 195 This is to guarantee immutable tamper-proof traceability, with a potential of building up evidence-based larger datasets of tracked eBPF performance over time - prerequisite infrastructure datasets enabling large-scale, broader, and consequently more reliable and objective comparative analyses and industry evaluation studies in the future. 6.2 ELASTIC Developments on WebAssembly Security Stack smashing is a type of memory corruption vulnerability that occurs when a program writes more data to a stack-based buffer than it can hold, overwriting adjacent memory and potentially allowing attackers to hijack control flow or execute arbitrary code. This class of vulnerabilities has historically been a major security concern in native environments like C/C++, leading to exploits such as buffer overflows and return-oriented programming. While Wasm was designed with strong safety guarantees such as bounds checking and structured control flow, it is increasingly being used to compile unsafe languages and run complex workloads, including in trusted execution environments and IoT devices. As such, addressing stack smashing in WebAssembly is critical to maintaining its security posture, especially when integrating legacy code or enabling low-level memory manipulation. Ensuring robust defences against stack smashing helps preserve Wasm’s sandboxing model and supports its adoption in security-sensitive applications. 192 C. Liu, B. Tak and L. Wang, “Understanding Performance of eBPF Maps”, in Proceedings of the ACM SIGCOMM 2024 Workshop on eBPF and Kernel Extensions (eBPF '24), 2024, Association for Computing Machinery, New York, NY, USA, 9–15. https://doi.org/10.1145/3672197.3673430 193 J.Lawall, M.Derri and K.Lazri, ”Performance evaluation of the Linux kernel eBPF verifier”, FOSDEM 2025 freeand open-source software community event, Brussels, https://fosdem.org/2025/schedule/event/fosdem-2025-6453-performanceevaluation-of-the-linux-kernel-ebpf-verifier 194 M.H.N. Mohamed, X. Wang and B. Ravindran, “Understanding the Security of Linux eBPF Subsystem”, in APSys 2023 - Proceedings of the 14th ACM SIGOPS Asia-Pacific Workshop on Systems, 87–92. https://doi.org/10.1145/3609510.3609822 195 P. Hlushchenko and V. Dudykevych, "Harnessing Blockchain and eBPF for Immutable Audit of System Events: a Technological Convergence Approach", in: Ukrainian Information Security Research Journal, Vol. 26 No. 1 (2024), https://doi.org/10.18372/2410-7840.26.18844
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 97 - August 31, 2025 This subsection presents ELASTIC’s hardened implementation of Stack Smashing Protection (SSP) for WebAssembly. This well-established mitigation prevents vulnerabilities arising from buffer overflows. Previous studies, such as the one by Lehmann et al., have highlighted the importance of SSP for protecting Wasm binaries against memory corruption. Although a basic SSP mechanism has been introduced in LLVM-based toolchains for standalone WebAssembly binaries, it has not undergone an in-depth security validation. This paper sought to determine whether this protection was effective in practice and to strengthen it where necessary. A systematic evaluation of the existing SSP implementation was conducted using three security properties adapted from the literature on native SSP systems: • P1 – Secrecy of the Canary Value: The canary value inserted into the stack must be unpredictable to an attacker. • P2 – Safe Storage of the Reference Canary: The reference value must be isolated from attacker-controlled memory and protected against overwrites. • P3 – Immediate Termination on Detection: The program must terminate as soon as a corrupted canary is detected. The evaluation revealed two critical weaknesses: • When randomness could not be obtained from the host environment (e.g., via the WASI random_get function), the library fell back to a deterministic, guessable value, violating P1. • The reference canary value was stored in linear memory, which is fully writable and potentially accessible via buffer overflows, violating P2. On the other hand, the implementation correctly aborted execution immediately upon detecting a corrupted canary, satisfying P3. Several popular standalone Wasm runtimes were tested under constrained conditions to simulate restricted entropy sources. The experiments confirmed that several runtimes either failed to provide secure randomness or crashed, further exposing the fragility of the existing SSP implementation. To address these issues, the following changes were made to the SSP implementation: • The reference canary value was moved from the linear memory into a WebAssembly global variable. This area is managed by the virtual machine and cannot be accessed or modified by linear memory operations, making it a secure location for sensitive values. • The fallback behaviour for random number generation was revised. Instead of defaulting to a predictable value, the library now aborts the program during startup if randomness cannot be securely obtained. This prevents execution under insecure conditions. These modifications were implemented directly in LLVM and wasi-libc, preserving compatibility with existing WebAssembly standards and tools. All changes were published as open-source. The project made several concrete contributions to WebAssembly security: • A hardened implementation of SSP for Wasm using LLVM and wasi-libc. • A methodology and adapted tooling (based on CookieCrumbler) to assess SSP robustness in Wasm binaries. • A proof-of-concept demonstration of bypasses and remediations. • A publicly available codebase for researchers and developers seeking to adopt or build on this work.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 98 - August 31, 2025 Given the increasing use of WebAssembly for running memory-unsafe code compiled from languages like C and C++, a strong default SSP implementation is essential. The work presented here is generalisable to other WebAssembly toolchains and environments, and can serve as a foundation for future security enhancements. This work demonstrates that meaningful improvements to Wasm security are possible today without requiring changes to the WebAssembly specification itself. As such, it represents an important step toward making WebAssembly a safer platform for high-assurance and high-risk applications. This work was reported in a paper that was presented at the PLAS 2024 workshop 196 and accepted at FNWF 2024 197 in a shorter version. 196 Quentin Michaud et al, "Securing Stack Smashing Protection in WebAssembly Applications,", presented at the 19th Workshop on Programming Languages and Analysis for Security (PLAS 2024), 2024. 197 Q. Michaud, Y. Pipereau, O. Levillain and D. Ayed, "Robust Stack Smashing Protection for WebAssembly," 2024 IEEE Future Networks World Forum (FNWF), Dubai, United Arab Emirates, 2024, pp. 861-866
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 99 - August 31, 2025 7 ELASTIC Architecture and Components Although the ELASTIC work plan did not initially dedicate a specific task to architectural design, it became evident early on in the project that establishing a common architecture was essential to support and coordinate technical development across all WPs. Given the diversity of technologies involved - from confidential computing and WebAssembly to orchestration, migration, and secure workload execution - a unified architectural vision was required to ensure alignment and integration. To address this need, the consortium agreed to incorporate the architectural work into D1.1, leveraging the broad participation of partners within WP1. The architecture was developed collaboratively from M04 to M12. Contributions were gathered through a series of online technical workshops and dedicated sessions during plenary meetings. These interactions allowed technical partners to present their planned components, outline assumptions, identify dependencies, and refine integration strategies. As a first step toward defining the architecture, a shared template was circulated to collect information at the component level (the template is attached in Annex I – Section 9). This initial collection included description, added value, progress beyond SOTA, inputs, outputs, functionality, associated demonstrators, ownership, and requirements. The purpose of this activity was to create a consolidated view that would inform the initial architectural design. While this information served as the foundation for the architecture, it will continue to be updated and refined within the relevant technical WPs as components mature and integration progresses. For the purposes of this deliverable – given its already substantial size – we include only the part of the template covering the basic component description, added value and innovations, progress beyond the state of the art, and initial and estimated TRLs. The remaining information, although collected, served as a driving force for WP5 integration activities and demonstrator development, and will continue to guide the project’s technical work in subsequent deliverables. The process resulted in a logical architecture that reflects both the horizontal capabilities - such as monitoring, access control, and orchestration - and the vertical innovation paths needed for demonstrator-specific implementations. This section introduces the consolidated ELASTIC high-level architecture and the components that compose it, as defined by contributions from across the consortium. It presents the conceptual model guiding the technical evolution of the project and offers a shared reference for implementation, integration, and validation activities. Additional resources, such as the ELASTIC architecture diagram and the online component catalogue, provide supporting detail and will continue to evolve alongside the technical work. The following subsections outline the architecture design methodology, the core capabilities supported, the key functional building blocks and their interactions, and the logical interfaces that enable secure and efficient communication between components. Together, they form the foundation for technical integration efforts and demonstrator-specific architectures presented in other deliverables. 7.1 Architectural Scope and Objectives An incremental and iterative process for designing the ELASTIC framework has been adopted. The design process is tailored to the overall concept underpinning the project. In particular,
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 100 - August 31, 2025 ELASTIC aims to enhance the efficiency and security of service orchestration within the highly distributed and heterogeneous context of cloud-fog-edge continuum technologies. To achieve this goal, the design process starts by capturing the architectural functionality and requirements. Then, in order to meet our vision of empowering the following innovative key technologies in ELASTIC: Wasm, eBPF/XDP, Serverless FaaS, and Confidential computing, an investigation of these technologies and the role that they can play in the architecture has been carried out. Based on the knowledge gained from the conducted investigation and the identified requirements, we defined the potential functional blocks that make up what we call the highlevel architecture or the logical architecture of ELASTIC. The ELASTIC functional blocks are classified into categories according to their main role in the architecture in order to define the core building blocks of the architecture and identify the envisioned services to be provided by each block. Then, each functional block is specified and its added value in the architecture, macro-level interactions, dependencies, and interfaces are analysed. The design process then continues with the detailed demonstrator Use Cases, the architecture instantiation on these pilots, and the technical components integration of the architecture. The following subsections focus on the resulting ELASTIC high-level architecture. The technical instantiation of the architecture and the technical integration of its components is described in D5.1 198 . 7.2 Design Principles and Cutting-Edge Capabilities The ELASTIC architecture is designed around a set of foundational principles that ensure both modularity and holistic integration. Each component within the architecture is conceived to be independently valuable—capable of delivering tangible benefits as a standalone solution— while also being designed to seamlessly integrate into a broader, cohesive system. This dualpurpose design philosophy enables flexible exploitation strategies: stakeholders can choose to adopt and deploy individual components in isolation, or leverage the full power of the ELASTIC framework by combining multiple components into a unified, interoperable platform. This approach supports a wide range of deployment scenarios, from lightweight edge nodes to complex cloud–edge–IoT infrastructures. It also ensures that innovations developed within the project can be reused, extended, or commercialised independently, thereby maximising the impact and sustainability of ELASTIC outcomes. 7.2.1 Preparing Integration Through an Abstract Architecture The architecture presented in this deliverable serves as an abstract, conceptual blueprint that illustrates how the various components and technologies developed across the project can interoperate. It defines the logical structure and interaction patterns between the five core architectural blocks: Orchestration, Isolation, Communication, Monitoring & Detection, and Trust & Access Control. The accompanying component tables provide a high-level mapping of how individual modules interface with one another, including their expected inputs, outputs, and integration points. These tables are not prescriptive, but serve as a flexible guide for instantiating the architecture in different contexts. 198 ELASTIC Project, Specification of the ELASTIC Demonstrators and validation plan (Deliverable D5.1), to appear.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 101 - August 31, 2025 7.2.2 Instantiations Across Work Packages and Demonstrators This abstract architecture will be instantiated in multiple ways throughout the project: • Demonstrator 1 will showcase the architecture in the context of secure, low-latency orchestration for 6G IoT data fabric services, emphasising lightweight deployment and edge intelligence. • Demonstrator 2 will focus on secure workload migration and trusted execution across heterogeneous infrastructures, highlighting the architecture’s support for confidential computing and attestation. • Some Individual Work Packages will provide a more in-depth technical architecture to dive deeper into individual subsections of the general architecture. For example, WP3 is developing an instantiation focused on confidential computing capabilities, including TEEs, secure workload isolation, and attestation mechanisms. Each instantiation will tailor the abstract architecture to specific technical and operational requirements, demonstrating its flexibility and extensibility across diverse use cases. 7.2.3 Enabling Cutting-Edge Capabilities The architecture is designed to support and integrate a range of cutting-edge technologies, including: • Wasm for portable, sandboxed execution across heterogeneous platforms. • eBPF for in-kernel programmability, enabling real-time observability, policy enforcement, and network acceleration. • WASI and WasmHAL for standardised system interfaces and secure hardware abstraction. • AI-enhanced Intrusion Detection Systems for proactive threat detection and response. • Remote Attestation and Confidential Computing to ensure trust and integrity in distributed environments. • Serverless Orchestration and Federated Learning for scalable, privacy-preserving AI at the edge. By combining these technologies within a modular yet integrated framework, ELASTIC aims to deliver a next-generation orchestration platform that is secure, efficient, and adaptable to the demands of 6G and beyond. 7.3 High-Level Architecture Overview This section presents a conceptual view of the ELASTIC architecture, highlighting the major components, their interactions, and how they jointly support the overall vision of the project.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 102 - August 31, 2025 Figure 16. ELASTIC conceptual architecture. The architecture is organised around 5 building blocks: • The Orchestration block manages services across diverse cloud-fog-edge infrastructures, enhancing scalability, flexibility, and security. This block also has the role of optimising the deployment and coordination of workloads across these distributed environments, enabling resource-efficient and secure service delivery. • The Isolation block enables secure, privacy-preserving computation across cloud, fog, and edge infrastructures. It is designed to protect data from Wasm and eBPF tools, ensuring that sensitive information remains isolated from potential threats during execution. This block leverages TEEs, secure elements, and automated security tooling guarantees so that data confidentiality and integrity are maintained. • The Communication block supports secure data transfer across edge, fog, and cloud environments, but it also ensures a high-performance data exchange. For that, it leverages advanced technologies, such as eBPF and RDMA, to optimise communication speed. It plays a vital role in enabling low-latency orchestration of Function-as-aService (FaaS) workloads, ensuring that ELASTIC’s platform is scalable for next-gen computing. • The Monitoring & Detection block ensures continuous, efficient security monitoring for edge, fog, and cloud infrastructures. This block leverages technologies, like eBPF and AI-based intrusion detection, to detect vulnerabilities and monitor network activity. • The Trust & Access Control block guarantees secure, authorised access to sensitive data and workloads through advanced remote attestation platforms and fine-grained access control solutions to ensure that only trusted entities can access critical resources. The ELASTIC architectural building blocks interact through the following logical interfaces: • The “Attestation” interface informs the Trust & Access Control block when a workload is ready to be attested and verified.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 103 - August 31, 2025 • The “Standardised Workload Packages” interface is used to ensure the hand-off of workloads to the isolation block, to execute the workloads in an isolated environment. This interface will build on existing standardised workload package formats such as OCI images, and extend them to include additional metadata relevant to the ELASTIC technologies. • The “Observe, Check, Act” interface is responsible for monitoring the lifecycle state of running workloads and infrastructure so that any differences between the desired state of workloads and the actual state of workloads can be reconciled. • The “eBPF” Interface (Communication ↔ Monitoring & Detection) enables deep observability and efficient data flow between the Communication and Monitoring & Detection blocks. It leverages eBPF’s in-kernel programmability to provide real-time insights into network traffic and system behaviour without performance degradation. This interface allows the Communication block to expose critical telemetry and performance metrics, while enabling the Monitoring block to analyse these data streams for anomalies, intrusions, or performance bottlenecks. As a result, it facilitates lowlatency, secure communication that is continuously monitored and adaptable to evolving threat landscapes. • The “WASI” Interface (Communication ↔ Isolation) enables secure and portable data exchange between the Communication and Isolation blocks by leveraging the WebAssembly System Interface. This interface ensures that communication processes can securely interact with isolated execution environments without violating sandboxing or confidentiality constraints. It facilitates the delivery of data to Wasmbased workloads while preserving integrity, enforcing strict access boundaries, and supporting cross-platform compatibility. By abstracting low-level system interactions, the WASI Interface promotes modular, secure communication with minimal runtime overhead—essential for privacy-preserving edge-to-cloud workflows. • The “Access Control” Interface enforces secure and policy-driven interactions between the Trust & Access Control and Isolation blocks. It ensures that only authenticated and authorised entities can initiate or access isolated workloads, leveraging fine-grained access policies and identity verification mechanisms. This interface supports runtime enforcement of trust policies, integrates with remote attestation protocols, and governs the execution of sensitive computations within TEEs or other isolation technologies. By aligning access decisions with platform-wide trust anchors, it strengthens data protection and mitigates unauthorised access risks across distributed infrastructures. • The “Measurement” Interface (Trust & Access Control ↔ Isolation) enables the secure collection and verification of integrity metrics from isolated environments, serving as a critical link between the Trust & Access Control and Isolation blocks. It facilitates the extraction of cryptographic measurements (e.g., hash-based evidence) from TEEs, containers, or other isolation technologies. These measurements are used in remote attestation workflows to assess the trustworthiness of a workload before granting access or execution privileges. By providing verifiable evidence of runtime integrity, the Measurement Interface ensures that trust decisions are based on tamper-proof, runtime-generated data, reinforcing the platform's end-to-end security guarantees.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 104 - August 31, 2025 7.4 Core Building Blocks This section presents all the components present in the ELASTIC architecture per building block, and their relations to work packages, partners, and demonstrators. The requirements, inputs, and outputs that were collected are described as part of the demonstrator description in D5.1. 7.4.1 Management & Orchestration Table 6: Federated Learning as a Service (FLaaS) - TID. Component Name Federated Learning as a Service (FLaaS) Component Owner TID Relevant WPs WP4 Relevant Demonstrator N/A Type Software Description TID has designed and continued building the first Federated Learning as a Service (FLaaS) platform, which allows third-party applications and services to build FL models in a seamless and transparent fashion on user devices, as well as to collaborate with each other and build joint FL models that solve existing or novel ML models on more (combined) data. FLaaS is contributing to the orchestration aspect of ELASTIC, and in particular, the Federated AI orchestration functionality. TID is currently extending the functionality of FLaaS to include Split Learning (SL), which is a generalisation of FL in which devices (clients) can offload the training of part of their model to more computationally powerful devices (helpers). A main advantage of SL over FL is that it allows for resource-constrained devices to participate in the training. The participation of such devices in the training, while also limiting the negative impact that can be incurred (e.g., a significant increase in the training time, security issues), is one of the challenges that ELASTIC seeks to overcome. Added Value & Innovations TID will extend the existing component that is FLaaS as part of ELASTIC. To mitigate the possible negative impacts of including resource-constrained devices in SL, TID plans to develop and incorporate a new efficient algorithm in FLaaS that will optimise the assignment of clients to helpers and the scheduling at the helpers to minimise the training time. Furthermore, in regards to security concerns, TID will extend FLaaS to include the use of TEEs to ensure secure privacy-preserving SL. These extended functionalities of FLaaS in combination with the new efficient algorithm will contribute to the development of a framework that allows heterogeneous resource-constrained devices at the edge to participate in the training of models in an efficient, secure, and privacy-preserving manner, a major objective of WP4. Progress Beyond the SOTA FLaaS will extend beyond the state-of-the-art through the design and incorporation of a new efficient algorithm for SL that will decide on the assignment of clients to helpers and the scheduling at the helper in order to minimise the training time. In particular, for this problem, TID will aim to provide the first algorithm with theoretical guarantees on the optimality of its solution. Indeed, the current algorithms in the literature are only heuristics, and thus, may provide solutions that are arbitrarily bad. Furthermore, TID’s plans to enhance the functionality of FLaaS to include SL with TEEs will create the first framework with this functionality and the first study of these combined features. Initial TRL 4 Estimated TRL 5
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 105 - August 31, 2025 Table 7: Wasm-operator - IMEC. Component Name Wasm-operator Component Owner IMEC Relevant WPs WP2 Relevant Demonstrator Demonstrator 1 Type Software component integrating in Kubernetes Description Runtime for running Kubernetes operators in WebAssembly. Kubernetes Operators are plugins to the Kubernetes control plane. They manage resources inside of Kubernetes and add higher-level functionality such as the ability to manage database clusters. The goal of this project is to improve the memory usage of a Kubernetes cluster by reducing the memory footprint of operators. This prototype reduces the overhead in three ways. It runs operators in a shared WebAssembly runtime to reduce the overhead of containerisation. It swaps operators to disk when there are no changes to process. It uses the Rust programming language instead of Go. This framework ensures that Kubernetes-based orchestration platforms in ELASTIC run better on resource-constrained devices. This framework has support for regular operators built with the kube-rs SDK. It has a patched version of the kube-rs SDK that uses the system interfaces of this framework to communicate with the Kubernetes API instead of contacting the Kubernetes API directly. Added Value & Innovations At the start of ELASTIC, this project was a rough PoC only tested using unrealistic workloads. As it was only TRL 3, it was only tested using a number of different synthetic operators that change certain values in the Kubernetes API. Moreover, the prototype only restarted operators at the moment a change event was sent to the parent operator. As part of ELASTIC we are adding predictive unloading and rescheduling to the framework, so that operators can be restarted just before a change event will be received. This will reduce the cold start latency of the operators. Moreover, we will be testing and benchmarking the framework using realistic data and workloads to get a more realistic view on the performance improvements of the framework. Finally, we will be extending the framework to improve support for existing operators, and greatly improving the developer experience to enable wider uptake by the Kubernetes community. Progress Beyond the SOTA Some WebAssembly-based Kubernetes control plane plugin systems already exist but only provide limited functionality such as wasm-based plugins to the scheduler or frameworks like Open Policy Agent. These frameworks solve one specific problem and only allow to change the behaviour of one specific part of the Kubernetes control plane. In contrast, operators are generic plugins that can change almost any functionality. The challenge with operators specifically is that their frameworks and SDKs do not support running workloads in Wasm and are focused on long-running processes which are constantly using resources, even when there are no changes to process. The wasm-operator framework, on the other hand, is a generic framework supporting any type of control plane logic that can be expressed in a Kubernetes operator. Moreover, by focusing on compatibility with the existing Kubernetes Operator ecosystem, it becomes trivial to reduce the overhead of already existing operators. Initial TRL 3 Estimated TRL 4 Table 8: Light-weight Security Orchestrator for Edge Devices - THS. Component Name Light-weight Security Orchestrator for Edge Devices Component Owner THS Relevant WPs WP3, WP4 Relevant Demonstrator Demonstrator 1
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 112 - August 31, 2025 designated for the CPU in this project is RISC-V, with Keystone identified as the preferred implementation for the TEE. THS will develop the component for transparent data interception and encryption originating from Wasm workloads and running within the enclaves. The component will send this data for encryption to the trustworthy physical root-oftrust of the platform. THD will provide a Secure Element as the targeted physical root-of-trust of the component and also the PKCS11 API to communicate with it. Added Value & Innovations This component provides a new level of security for sensitive data at-rest in TEE at the edge for WASM workloads running in enclaves. This contribution aligns with ELASTIC's goals by ensuring robust data confidentiality, fostering a more secure and resilient infrastructure for data handling within the project’s context. Demonstrator 1 will benefit from this component with transparent encryption for data at-rest and low footprint at the edge. Secure Elements are well-suited for edge devices that can be used as the physical root-of trust of the devices for this demonstrator. The other components of this project like the Wasm orchestrator and operators can interact with this component to configure dynamic and transparent encryption for data at-rest while scheduling Wasm workloads on the fly. Obviously, other components from ELASTIC can also interact with this one for a reliable access to cryptographic capabilities and keys from a physical root-of-trust. Progress Beyond the SOTA Data protection at-rest and more generally secure storage features are not available to Wasm workloads. There is currently no WASI interface providing such a feature to workloads. This can be easily explained by the objective of Wasm to be independent of the hosting platform allowing deployment of interoperable workloads. By adding support of data-at-rest protection, but relying on the transparent encryption design principle, the initial objective of keeping Wasm workloads platform-agnostic is preserved. Even if the existing TEEs implement some functionalities of TPMs or HSMs, they remain insufficient for protecting data at rest and are vulnerable to side-channel attacks, particularly when attackers have direct access to the storage medium or physical access to the hardware. Acknowledging these limitations, it is essential to adopt a better security strategy that includes robust data-at-rest encryption methods such as Full Disk Encryption (FDE), file-level encryption, and database encryption. This novel approach integrates tamper-resistant and physically dedicated root of trust like Secure Elements for enhancing the overall security of the Keystone and RISC-V architecture running Wasm workloads. Initial TRL 1 Estimated TRL 3 Table 14: WasmHAL-Trust: Automation tooling for confidential computing environments - LUN. Component Name WasmHAL-Trust: Automation tooling for confidential computing environments Component Owner LUN Relevant WPs WP3 Relevant Demonstrator Demonstrator 2 Type Software Description This component is part of the Wasm HAL-Trust component of the architecture. WP3 of ELASTIC addresses portable computing using confidential containers. The solution’s core is the ability to run Wasm applications on different confidential container platforms. The Hardware Abstraction Layer (HAL) specification is essential to enabling this and is essential to achieve the WP3 objectives regarding implementing privacy-preserving architecture-agnostic secure execution of
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 113 - August 31, 2025 workloads supporting multi-stakeholders and tenants. The HAL-Trust component is an extended WebAssembly interface allowing a common platform interface for all WebAssembly workloads with interoperable access to the platform trust functions. The Wasm HAL-Trust interface provided by the component is a WASIcompliant interface that extends the industry-standard WASI functions as defined by the Bytcode Alliance. Consequently, it offers WASI-compliant TEE functionality to security-sensitive WebAssembly applications. This software component is a reference implementation of the Wasm HAL-Trust interface. It will serve as a baseline for integration and adaptations to different TEE platforms, as well as the pilot WebAssembly TEE solutions. The reference implementation is not a ready-to-use solution, but a reference that can be used to adapt and integrate TEE HAL for different supported ELASTIC TEEs. In particular, this reference implementation can be used to test WebAssemby workload, as well as to test and verify platform-specific TEEs’ implementation of the Wasm HAL-Trust. Added Value & Innovations The ELASTIC WasmHAL-Trust component is a core enabler to realise the ELASTIC vision of secure, portable workload execution on different platforms and for different use cases. This can only be achieved through interoperable solutions among different TEE environments. The current WASI industry standard as defined by the Bytecode Alliance gives interoperable access to platform system functions for WebAssembly workloads. However, in order to take full advantage of essential security functions provided by trusted execution platforms, the current WASI standard is not enough. We have carefully evaluated the needs and opportunities for new WASI-compatible enablers and through the new ELASTIC WasmHAL, new security use cases such as secure migration, protected storage, and parameter sealing are enabled. The TEE HAL must be supported by all ELASTIC-compatible TEE runtimes. Hence, the component is an essential part of the ELASTIC architecture. The reference implementation will be used as a basis for the implementation of trusted WebAssembly execution and for testing different TEE HAL realisations. Progress Beyond the SOTA The TEE HAL is following the ByteCodeAlliance standard for WebAssembly interfaces (WASI). The current WASI 0.2 has limited functionality. In particular, it does not provide adequate support for running protected Wasm on TEEs. To give adequate support beyond the current WASI standard is not straightforward. Indeed, the functions to support services, such as WebAssembly migration and protected analytics, require a detailed analysis of the requirements and then selection of the appropriate interface function families allowing realisation on different TEE platforms without affecting the interoperability. This is the core contribution of the new ELASTIC WasmHAL-Trust component. Initial TRL 3 Estimated TRL 4 Table 15: WASI Security - IMEC. Component Name WASI Security Component Owner IMEC Relevant WPs WP2 Relevant Demonstrator Demonstrator 1 Type Software Description This is a set of security adaptations for WebAssembly runtimes to specify the allowed (access control) permissions of a WebAssembly component and to mediate calls from a WebAssembly Component to external resources. This software creates the bridge between the security functionalities of the WebAssembly runtimes and the higher-level orchestrators. The purpose of this software is firstly to ensure there is a standardised way to describe the permissions of a WebAssembly component in
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 114 - August 31, 2025 a policy assertion document. These permissions can include things like what USB devices a component has access to, what files a component is allowed to access, and how it is allowed to interact with other components. Higher-level security orchestrators can then use this document to communicate to the runtime what a component is allowed to do. Secondly, this software implements low-level mediation of interfaces and granting of permissions in the WebAssembly runtime. This allows a runtime to read the policy assertion document, and apply the security policies described there. The ELASTIC consortium is building a number of security technologies to isolate WebAssembly components and give them mediated access to outside resources. The purpose of this software is to be the bridge between these security technologies and higher-level orchestrators. This software ensures that there is a way to describe the security policies of an individual component and to apply these security policies in the runtime by using the other security technologies built as part of ELASTIC. Moreover, by recording and remotely attesting the policy assertion document, external services and operators can verify the permissions and isolation of a component. Added Value & Innovations This is completely new software that will plug into existing WebAssembly runtimes such as Wasmtime and WAMR. While these runtimes already allow mediating some access to external resources, this support is limited and the format to communicate security policies to the runtime is different for every runtime. Our goal is to create a plugin supporting a standardised format for policy assertion documents that is supported in multiple WebAssembly runtimes. We will create the proposed standardised document format, implement the tools for reading and writing these documents, and implement a plugin for a WebAssembly runtime that reads these documents and applies the policies appropriately. Progress Beyond the SOTA While a lot of standardised solutions exist to describe and package workloads, there is little work describing a standardised format to specify the security policies of a workload. At the moment, each WebAssembly runtime has their own format of runtime flags and APIs to specify workload security policies. While the WAC specification format describes how to compose components, it does not describe what security policies to apply to component interfaces. Moreover, even in the more mature Docker ecosystem, no standardised format exists for describing workload security policies. Some orchestrators such as Kubernetes allow specifying security policies, though these specifications are not cross-platform, are often specific to a specific isolation framework, and often require third-party plugins to make them truly secure. Initial TRL 2 Estimated TRL 4 Table 16: Automatic MAC profiles for Wasm runtime containers. Component Name Automatic MAC profiles for Wasm runtime containers Component Owner LUN Relevant WPs WP1 Relevant Demonstrator N/A Type Software Description Wasm runtime security is a cornerstone in the ELASTIC architecture. This will be achieved using several different mechanisms and protection means.An important part of a secure framework for protecting the platform where the WebAssembly is executing is restrictive access control. This is the mechanism covered by the Mandatory Access Control profile component. The MAC profile generator can be used to examine the necessary WebAssembly Permissions needed to execute successfully. This includes resources such as file system access, networking, or specific system calls. Access profiles serve to restrict
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 115 - August 31, 2025 what each WebAssembly module can do, thus minimising the attack surface and ensuring that malicious or compromised binaries cannot exploit the runtime environment. When running Wasm on platforms like Docker, creating unique profiles allows each Wasm module to operate with the least privileges necessary for its execution. To automate this process, a profile generator will be developed that integrates directly with the Wasm runtime and its executed platform. This tool is to automatically create profiles for the access needs of an application during tests such that its privileges can be minimised. The tool covers access right identification that, in the next step, can be connected to a MAC enforcement layer.. Added Value & Innovations When multiple WebAssembly applications run simultaneously on a single platform, there is a risk that a hostile code or a vulnerability in one application will influence other applications. One way of reducing that risk is to reduce the privileges when running WebAssembly as much as possible. Mandatory Access Control is a powerful concept to achieve this. While a good MAC framework exists for Linux and Containers etc., there is no current tool for determining a WebAssembly application's access needs. To get a suitable access profile for a WebAssembly workload is the first step to restricting the workload's access rights. The next step is to enforce such policies. No tools for profiling WebAssembly workloads are currently available, and that is the gap this component fills. Automatic access profiling of Wasm applications will help in increasing the overall security when running Wasm on different platforms. Platform-wide support and interoperability, is a key expectation according to the ELASTIC architecture. Even if manual profiling of .wasm is possible, that is often tedious work subject to human error. Hence, this tool enhances the security of .wasm deployments. Progress Beyond the SOTA Major mandatory access frameworks exist for platforms like Linux. The most widely known are SE-Linux and AppArmor. Tools for making access profiles for Docker containers using AppAmror have been extensively researched and exist in today's market. Similarly, lots of research efforts have been devoted to tools to help set up SE-Linux profiles for applications. However, no tools to profile WebAssembly workloads have been researched or are available. Even if it would be possible to run Docker profiling of the Wasm applications, that will not give the same enforcement possibilities when using a Wasm runtime. Hence, adding access profiles to Wasm that have been automatically generated is a new and most useful addition from a security perspective. Initial TRL 3 Estimated TRL 4 Table 17: WasmHAL Hardware SDK, interfaces, and runtime extensions for securely connecting Wasm applications to hardware across platforms - IMEC Component Name WasmHAL Hardware SDK, interfaces, and runtime extensions for securely connecting Wasm applications to hardware across platforms Component Owner IMEC Relevant WPs WP2 Relevant Demonstrator Demonstrator 1 Type Software Description This is an SDK and a set of standardised interfaces for compiling hardware drivers and hardware abstraction layers to Wasm, providing interfaces for application connection to packaged HAL, and runtime extensions that enable curated access to underlying hardware through a WebAssembly runtime. More specifically, this includes WASI proposals and proof-of-concept implementations to enable WebAssembly to have hardware interaction with I2C , USB and more commonly used IoT and cyber-physical protocols. This allows running the device drivers within WebAssembly as well. A thorough evaluation of the proof of concepts
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 116 - August 31, 2025 shows that WASI-USB introduces a minimal overhead of at most 8% compared to native operating system USB APIs. Added Value & Innovations This work will use the existing WebAssembly and WASI technologies as a foundational HAL. However, WASI currently has very little support for connecting WebAssembly to hardware. Instead, WASI is mostly focused on Cloud use-cases such as HTTP applications or webservers. Therefore, we will extend WASI with new interfaces to connect WebAssembly applications to hardware, such as USB, I2C, SPI, GPIO (digital IO), and CAN bus. Moreover, we will work with the ByteCode Alliance and the WASI standardisation committee in order to ensure WASI is performant enough to support these interfaces, which have very low latency requirements. Progress Beyond the SOTA While some WASI interfaces specific to Cloud computing already exist, they do not support functions necessary for IoT devices, such as accessing hardware devices via USB. Lauwaerts et al.202 developed the WARDuino virtual machine (VM), which exposes Arduino APIs for GPIO (General-Purpose Input/Output), SPI (Serial Peripheral Interface), ADC/DAC (Analog to Digital and Digital to Analog Converter), and PWM (Pulse Width Modulation) to the Wasm runtime. WARDuino only facilitates the use of Wasm in, as its name suggests, Arduinobased projects. This poses notable limitations in terms of portability. This also means that the hosting device must provide all the necessary APIs and that there is no hardware support beyond the Arduino ecosystem. Aerogel203 is a lightweight access control framework that addresses security gaps between the bare-metal IoT devices and the Wasm execution environment concerning access control for sensors, actuators, processor energy usage, and memory usage. Aerogel enhances the security and provides resource management in multi-tenant Wasm runtime environments, where each Wasm application is considered a tenant. Aerogel allows sensor and actuator interaction by exporting high-level sensing and actuation functions to the WebAssembly Micro Runtime. A user-defined access control specification sheet allows one to set restrictions on specific I/Os, limitations on the number of accesses within a specified time frame, an upper bound on memory and CPU usage, and the maximum number of applications having shared access to a specific hardware component. Access to the requested resource will only be granted if all access control conditions are met. WiProg204 is a framework designed to simplify integrated IoT programming and application development for sensor-to-edge systems by employing Wasm, with a focus on application offloading. It allows for a monolithic application development approach which allows WiProg to perform offloading of the application based on compiler annotations and offloading policies. WiProg provides hardware-agnostic APIs to access peripherals on IoT devices, but these are limited to analogue I/O, digital I/O, and Universal Asynchronous Receiver-Transmitter (UART) APIs, thus lacking support for other important protocols like I2C. Li et al.205 proposed WAIT, a lightweight Wasm runtime for resource-constrained IoT devices for device-cloud integrated applications. It enables Wasm ahead-oftime compilation targeting resource-constrained devices. When a device running WAIT receives a Wasm module binary, it performs on-device AOT compilation, checks sandboxing guarantees, and finally executes the module. To cope with the 202 T. Lauwaerts, R. G. Singh, and C. Scholliers, “WARDuino: An embedded WebAssembly virtual machine,” Journal of Computer Languages, vol. 79, p. 101268, Jun. 2024, doi: 10.1016/j.cola.2024.101268. 203 R. Liu, L. Garcia, and M. Srivastava, “Aerogel: Lightweight Access Control Framework for WebAssembly-Based BareMetal IoT Devices,” in 2021 IEEE/ACM Symposium on Edge Computing (SEC), Dec. 2021, pp. 94–105. doi: 10.1145/3453142.3491282. 204 B. Li, W. Dong, and Y. Gao, “WiProg: A WebAssembly-based Approach to Integrated IoT Programming,” in IEEE INFOCOM 2021 - IEEE Conference on Computer Communications, May 2021, pp. 1–10. doi: 10.1109/INFOCOM42981.2021.9488424. 205 B. Li, H. Fan, Y. Gao, and W. Dong, “Bringing webassembly to resource-constrained iot devices for seamless device-cloud integration,” in Proceedings of the 20th Annual International Conference on Mobile Systems, Applications and Services, in MobiSys ’22. New York, NY, USA: Association for Computing Machinery, Jun. 2022, pp. 261–272. doi: 10.1145/3498361.3538922.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 117 - August 31, 2025 limited resources, the compile-time memory footprint is reduced by streamed lookback compilation. To access peripherals and I/O, native APIs are provided by the WAIT runtime and are exposed via the import mechanism of Wasm. The AOT compiler then performs binary rewriting techniques to replace the instructions that call the imported function with assembly code that directly accesses the peripheral, reducing the overhead associated with calling an external function. Finally, Wasmachine206 is a bare-metal operating system designed for embedded devices. It operates without protection rings by running everything in kernel mode, allowing for zero-cost system calls. The Wasmachine kernel exports system calls in WASI prototypes and runs each Wasm application as a kernel thread, allowing the application to invoke system calls as normal function calls without incurring additional context switching costs. Wasmachine allows access to hardware by using WASI, where access permissions are configured on a per-application basis and none are granted by default. Despite its innovative approach, the system has certain limitations, including limited support of CPU architectures and the reliance on a Unix-like monolithic kernel architecture, which can limit the feasibility on certain IoT or edge devices. Initial TRL 2 Estimated TRL 4 Table 18: Static eBPF code security Analyser - POLITO. Component Name Static eBPF code security Analyser Component Owner POLITO Relevant WPs WP1 Relevant Demonstrator Demonstrator 1 Type Software Description One of the issues experienced by eBPF code developers is the difficulty of understanding and fixing the errors raised by the eBPF verifier. This difficulty arises mainly from the absence of tools that can detect such issues early, i.e., at compile time, whereas the developer may get error messages late, i.e., at load time. Moreover, such messages are difficult to understand for the C programmer, especially since they are related to the bytecode and not to the original C source code. The static eBPF code security analyser is a software tool that can analyse eBPF C source code and spot the security vulnerabilities that prevent the code from being accepted by the verifier, providing the developer with clear-to-understand and early error messages, contrary to what happens currently. A second goal of the tool is also to provide the developer with fix suggestions related to the original C source code, making the fixing of the code easier and faster for the programmer. The tool will be part of the ELASTIC architecture as one of the development support tools offered to programmers for the development of the eBPF code used in the various eBPF-based architecture components, such as the eBPF distributed state synch or the accelerated microservices interaction. The tool is expected to improve code productivity and security, in relation to KPIs 1.2 and EO-KPI-6. Added Value & Innovations The static eBPF code security analyser is a new component that will be developed from scratch within ELASTIC. However, it will leverage the following existing components that are part of the usual eBPF developer support toolchain: 1) the Clang C compiler, which is the most commonly used compiler for eBPF code, with its framework for C code static analysis; 2) the eBPF verifier, which is part of the Linux kernel, activated at program load time. The added value of the static eBPF code security analyser, with respect to such existing components, will be the ability 206 E. Wen and G. Weber, Wasmachine: Bring IoT up to Speed with A WebAssembly OS. 2020, p. 4. doi: 10.1109/PerComWorkshops48775.2020.9156135.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 118 - August 31, 2025 to provide easy-to-understand error messages to the developer, along with fix suggestions, contrary to what happens with the current eBPF code development process. Specifically, the following functionalities will be included in the tool: 1) the precise identification (file, line number, and character) of the security-related error vulnerabilities in the C code that would cause the code to be refused by the eBPF verifier; 2) precise hints about how to remove such vulnerabilities and get the program accepted by the eBPF verifier. Progress Beyond the SOTA Research about enhancing the static analysis of eBPF code is limited to the verifier, which operates on the bytecode. Researchers have recently proposed ways to enhance the verifier, or formally analyse the code of the verifier itself, indicating some of its limitations, but not to report the same kind of issues early on during the code development process and with reference to the source code. The ELASTIC proof-of-concept eBPF code security analyser will fill this gap by providing early detection of security issues in eBPF C code, thus improving the eBPF code developer's experience. More precisely, the current developer experience is limited because the code developer does not receive hints at compile time about violations of programming rules that will lead to a code rejection by the eBPF verifier at load time or to security issues. Only at load time can the developer realise that something in the code is unacceptable, but the error messages returned by the eBPF verifier are difficult to interpret because they refer to the bytecode rather than the source code. Moreover, no hints are provided about how to solve the raised issues in the C code. Instead, with the static analysis tool that will be developed in ELASTIC, the developer experience will be improved since the developer will get precise error messages referring to the source code and hints about how to fix them. Initial TRL 2 Estimated TRL 3 7.4.3 Communication Table 19: Static analysis of interaction between Wasm modules - AAL. Component Name Static analysis of interaction between Wasm modules Component Owner AAL Relevant WPs WP1 Relevant Demonstrator Demonstrator 1 Type Software Description Systems of multiple Wasm components will often depend upon properties of each other, resulting in the need for checks during operation. If these checks can be determined statically, then we may improve performance by avoiding the need for these checks. This is particularly important given the move towards use of the Component Model: functionality will be split across several modules, and if modules are chained together in a way that introduces redundancy, then this may have a significant negative impact on performance. We therefore propose to develop ways to identify such redundancies by analysing code and/or metadata of the components in order to obtain a more optimised system, making highly-flexible componentbased systems viable in practice. Such analyses can also aid in the verification of attestation evidence: an application composed of multiple components will exhibit emergent behaviour that derives from the composition of the components, rather than from any individual component. Verification of attestation evidence from such a composition is challenging when the individual components are not fully fixed in advance, due to the combinatorial explosion of system configuration that occurs. Better high-level analysis of the application metadata will allow for agility of application components without degrading their ability to attest themselves.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 119 - August 31, 2025 Added Value & Innovations We propose to extend Wasm runtimes and development tools to validate certain properties (to be determined) of interactions between modules. We will develop interfaces that allow for the addition of custom access control capabilities to a WASI-based application, and identify forms of metadata and static analysis that can be used to characterise the behaviour of a combination of components and decide whether to replace them with a combined optimised component. We will also identify the necessary metadata and trust infrastructure needed to allow attestation verifiers to determine whether an agile system of varying components will behave as desired for the purposes of a specific application. We will determine how best to incorporate this into attestation infrastructure, whether by extending an existing tool such as Veraison to handle bundles of multiple attestations, or by developing a completely new tool that is able to interpret the combined output from Veraison and form it into a more meaningful application-specific set of claims. Progress Beyond the SOTA We have developed a protocol that allows distributed groups of components to collectively establish an application instance identity, thereby allowing other parties communicating with the application to ensure that the instantiated application is identical in structure to that of the expected application that has been analysed by the developer. Initial TRL 0 Estimated TRL 2 Table 20: Accelerated microservices interconnection - POLITO. Component Name Accelerated microservices interconnection Component Owner POLITO Relevant WPs WP2, WP1 Relevant Demonstrator Demonstrator 1 Type Software Description This component aims to improve the speed and latency of the communication between networked microservices that reside in either the same or multiple hosts. Traditional cloud-native software fully relies on the native network functions provided by the Linux operating system to ensure connectivity between the multiple microservices of any complex deployment. This however often entails traversing the software network stack multiple times as the inter-pod traffic is transported across network namespaces. In order to accelerate the performance of these interconnections, this component will make use of modern technologies provided by Linux - such as eBPF - to implement shortcuts in the stack, for example by utilising socket splicing or similar shared memory techniques to effectively speed up application-to-application data transfers. When data needs to cross the physical network, we similarly plan to adopt eBPF and/or RDMA to improve communication throughput. Added Value & Innovations The component will be fully researched and developed as part of the ELASTIC project by either building a network offloading solution from scratch (e.g., a Docker network driver), or extending an existing software stack, like the Cilium CNI; internal discussion will be needed to finalise the details of the component. A more efficient and faster network backend for services running on a distributed infrastructure will benefit ELASTIC's goal of defining a fast and secure orchestration platform for FaaS workloads. Progress Beyond the SOTA The current state of the art in terms of microservices interconnects is arguably defined by cutting-edge Kubernetes CNI providers such as Cilium. Some of these use eBPF acceleration to reduce the networking overhead associated with the delivery of network traffic between containers, by, e.g., employing Linux eBPFprogrammable netkit virtual devices to lower the cost of moving data in and out of
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 120 - August 31, 2025 secondary network namespaces, or by cleverly using the bpf_redirect_peer() eBPF helper to jump from a physical interface's TC ingress stage straight to the target pod's network namespace. The advancements explored within this component's boundaries go towards a complete bypass of the L3 and L2 (and in some cases L4, too) layers of the network stack for local container traffic by directly moving data between source and destination sockets, potentially massively increasing throughput and lowering latency. Additionally, the component is going to explore using RDMA technologies to speed up inter-host networking, once again an original contribution in this space. Initial TRL 1 Estimated TRL 4 Table 21: eBPF distributed state synchronisation - POLITO. Component Name eBPF distributed state synchronisation Component Owner POLITO Relevant WPs WP2 Relevant Demonstrator Demonstrator 1 Type Software Description This component is concerned with the development of techniques and algorithms for efficiently sharing state between application slices distributed in a computing cluster, as well as implementing fast consensus and leader election solutions capable of performing within ELASTIC's KPI2.3 of 100 microseconds in suitable conditions. The expected technologies to be used for this component are eBPF and/or RDMA, the former to implement crucial network stack shortcuts to shave off precious communication latency, and the latter as a full bypass of the network stack and for receiver-initiated communication paradigms. A possible application of this component's output would be an extension of Linux's eBPF map catalogue with variants that are automatically and transparently replicating across host boundaries. eBPF programs using these new maps would automatically achieve coherent data replication across a distributed computing domain, unlocking novel use cases for eBPF acceleration spanning multiple servers, e.g., a transparently converging routing table over a fleet of software routers, that would allow for load balancing of the routing network function over a cluster of nodes for improved performance and reliability. Added Value & Innovations The technology developed within this component is crucial for allowing efficient communication between the distributed computing blocks of the ELASTIC architecture, such as its innovative FaaS design. The entirety of this component's efforts are to be pursued within the ELASTIC project. The development of this component will follow a two-phase cycle, where the main functionality and algorithms will be devised and refined during the first phase (ensuring correct behaviour and proper performance) and a second phase which will delve into applying the developed techniques as custom eBPF map types, by extending the Linux kernel (for example through custom kernel modules) to be used by user-made eBPF programs. An optional third phase will focus on showcasing the achieved functionality via ad-hoc examples. Progress Beyond the SOTA Compared to the state of the art, the technology developed as part of this component will strive for the goal of distributing state within the 100 microsecond target imposed by ELASTIC, which equates to few round trip times even in high speed enterprise or datacenter networks.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 121 - August 31, 2025 Currently, eBPF programs running in various parts of the Linux kernel can share data among themselves and with user space controllers by utilising maps, of which the Linux eBPF subsystem implements several variants, to allow for, e.g., different access types and internal data layout constraints. However, none of the existing map types support automatically sharing their entries across multiple distributed workers; eBPF applications that wish to achieve data replication within a cluster must currently rely on their userspace controllers to implement the networking functionality necessary for achieving the desired effect, which forces users to keep userspace controllers around even for eBPF programs that would otherwise be pinned to sysfs nodes to run standalone. This component plans to obsolete this usecase by developing special map types that seamlessly replicate data between networked servers removing the requirement of relying on userspace controllers. Initial TRL 1 Estimated TRL 4 7.4.4 Monitoring & Detection Table 22: NETTO - A tool to measure the cost of the Linux network stack in real-time - POLITO. Component Name NETTO - A tool to measure the cost of the Linux network stack in real-time Component Owner POLITO Relevant WPs WP2 Relevant Demonstrator Demonstrator 1 Type Software Description NETTO is a utility designed to measure the CPU overhead associated with the execution of network functions (such as bridging, routing, filtering, and more) on Linux hosts. It uses eBPF to hook into low-level kernel monitoring interfaces. Specifically, NETTO is built around a custom sampling-based profiler that instruments Linux perf events to efficiently capture and parse CPU stack traces, which serve as the data source for the main CPU consumption metric extractor. With this powerful solution, NETTO achieves both (a) a remarkably low compute overhead, operating lightly enough on resources to support a continuous monitoring mode, and (b) virtually unlimited extensibility, where monitoring for new protocols and data paths can be seamlessly added without affecting the kernelside efficiency of the tool. Thanks to its low overhead and detailed instrumentation, NETTO can be run on ELASTIC nodes to monitor the cost of Linux networking in real-time. Information collected can be leveraged to drive the evolution of the accelerated networking components of the project, highlighting which steps of the network stack are the main bottlenecks in traffic processing, and hence, can benefit from optimisation or other forms of acceleration. Additionally, NETTO can help identify which kinds of traffic put the network stack under higher pressure, and hence, require more careful management. Added Value & Innovations The component will be adapted to fit ELASTIC's goals. On one hand, NETTO will need to gain a suitable output interface that allows it to be plugged into the rest of the ELASTIC infrastructure. Coordination with other components providing monitoring and observability will be needed to provide a cohesive platform. On the other hand, while NETTO has previously been validated in production clusters, running NETTO in the ELASTIC demonstrators will provide useful information on its efficacy in new deployment scenarios (serverless, IoT, etc.). This will enable further improvement of the tool if any shortcomings should be discovered, both in terms of the overhead of monitoring and in terms of coverage and granularity of the provided metrics.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 128 - August 31, 2025 output evidence in a standard format despite having a custom format, such as Attestation components within TEEs. The module for verification (or ”pre-verification”) of attestation evidence can be acquired on demand (e.g., from a TEE acting as an Attester, or from a source trusted from before) as a Wasm component for a specific TEE model. It is instantiated, e.g., in a generic Verifier service with an HTTPS API. The component knows the format and can verify the signature of platform-specific evidence, and produces attestation results in a standard format. Both the IETF RATS Background Check model and Passport model will be possible to use together with this mechanism. In Demonstrator 1, the component will be used for establishing trust through attestation towards data producers or consumers, executing in TEEs, in the Data Fabric. Added Value & Innovations Prototype implementation of a library and other needed components for abstracting selected vendoror provider-specific attestation procedures with suitable interfaces that map to, e.g., IETF RATS concepts. The starting point is a prototype developed in a Master's thesis (see thesis208 and thesis poster209). Initially, the prototype consists of a Wasm module that can verify SEV-SNP attestation reports, and which can be used with the VERAISON verifier framework. The prototype will be extended with support for additional HW platforms used in ELASTIC (e.g., TDX), with new interfaces (e.g., defined in WIT) for required inputs, Wasm module/component signature verification, and overall improvements. Progress Beyond the SOTA Standards for attestation evidence and results have started to emerge, but in practice they are typically specific to, e.g., TEEs from a specific vendor and of a specific type. Verification frameworks also exist (e.g., VERAISON), but the mechanisms for verifying evidence of a specific type are typically built into the framework, and thus, are also specific to that framework. Verification systems can thus benefit from being able to dynamically acquire the ability (e.g., via a Wasm module/component) to interpret and validate evidence for different TEE types, and produce results via a common interface and format. The concept has been prototyped in a Master's thesis, but its interfaces and capabilities need to be developed further for ELASTIC. Initial TRL 2 Estimated TRL 3 Table 30: Light-weight Attribute-based Access Control (ABAC) solution - THS. Component Name Light-weight Attribute-based Access Control (ABAC) solution Component Owner THS Relevant WPs WP2 Relevant Demonstrator Demonstrator 1 Type Software Description The solution aims to enforce attribute-based access control (ABAC) policies on Wasm orchestration, and also on interactions between Wasm containers and their environment. It mainly consists of user plane components playing the role of PEPs (Policy Enforcement Point) which may interact with control plane components for authentication, authorisation, and auditing policy enforcement. This is also an approach to apply the NIST Zero Trust Architecture (NIST SP 1800-35) to Wasm container environments. These PEPs are adapted for resource-constrained edge Computing devices, and are able to enforce an ABAC policy with the help of a PDP (Policy Decision Point) in 208 https://aaltodoc.aalto.fi/items/b79cddeb-3c78-44a9-aa47-2302fa1ad788 209 https://haic.fi/wp-content/uploads/2024/06/Multi-Platform_Attestation_Verification.pdf
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 129 - August 31, 2025 the control plane, not only on Management and Orchestration (MANO) operations on the devices, but also on the deployed Wasm containers' access to the edge computing host platform. These components will rely on the ELASTIC workload identity framework (including attestation) for authentication purposes prior to authorisation. This solution enhances the overall security of the ELASTIC FaaS orchestration system. Added Value & Innovations This is a new component aiming to enforce complex ABAC policies on the Wasm container execution and lifecycle management, addressing several challenges: ● Targeting a minimal footprint on the worker nodes, in terms of memory usage, CPU usage, and storage space. ● Targeting new resource-constrained embedded platforms, especially RISC-V (64 bit), therefore making sure the software implementation runs on such platforms. This is challenging as not all programming language SDKs (core standard library in particular) have been ported to RISC-V. This is still a work in progress, even for popular secure programming languages such as Rust. ● Resiliency to control plane unavailability: in particular, if the PDP (Authorisation Service) is unavailable because of network disruption, an infrastructure or application breakdown, or DoS (Denial-of-Service), the component should still operate properly and maintain security. Leveraging capability-based access control (CBAC) - combined with ABAC - should enable more decentralised and offline access control enforcement, and therefore a more resilient solution. Progress Beyond the SOTA This component will address several limitations. First, current Wasm orchestration frameworks do not support flexible ABAC (Attribute Based Access Control) policies (with OASIS standard XACML (eXtensible Access Control Markup Level) expressiveness for instance), or if they do, likely not in a suitable way for resource-constrained edge computing devices with limited memory and CPU capabilities. In particular, there is no such solution for the new generation of RISCV CPU architectures. Also, they may not work properly when the control plane, especially the PDP is unavailable due to DoS, network disruption, or infrastructure malfunction. In addition to addressing aforementioned limitations, this solution will take advantage of new subject (workload) attributes from ELASTIC Wasm workload identity (e.g., SPIFFE-based) and attestation framework, as well as new Wasmspecific action and resource attributes, e.g., based on WASI API calls. This should allow very fine-grained access control policy enforcement on Wasm containers' interactions with their environment, which includes not only the host, but also other containers, whether remote or on the same compute node. Initial TRL 3 Estimated TRL 4 Table 31: WASI flexibly-defined capabilities - AAL. Component Name WASI flexibly-defined capabilities Component Owner AAL Relevant WPs WP1 Relevant Demonstrator Demonstrator 2 Type Software Description WASI interfaces tend to use capability-based mechanisms for access control, e.g., the filesystem interface which allows one to obtain a handle that can be used to access files only beneath some given directory. This is effective where the restrictions are known at the time of standardisation, but in other cases an
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 130 - August 31, 2025 application might need to be subject to domain-specific access control restrictions, e.g., allowing only to write to files while maintaining some invariant such as compliance with a file format specification. In this component, we will identify how to provide these restrictions in a flexible and meaningful way, in order to ensure that the correct policies will always be applied to certain resources without hindering application development, whether using tools such as wasi-virt or other approaches, or a combination thereof. This solution enhances the overall security of the ELASTIC FaaS orchestration system. Added Value & Innovations We will develop a new API and possible tooling that will allow for arbitrary security policies to be applied to arbitrary interfaces. This may include completely new tooling, but there is the possibility to extend existing tools such as wasi-virt. Existing APIs provide domain-specific capabilities, and we will develop a way by which these can be wrapped by custom and attestable code that will restrict what is made available by the capability. This ties in with another component, "Static analysis of interaction", which will work in tandem with this to allow for custom capabilities to provide metadata allowing the identification of opportunities for chains of restrictions to be coalesced into a single filter. Together, these will allow attestation relying parties to be assured that resources and dataflows are adequately protected. Progress Beyond the SOTA Existing WASI capabilities are relatively inflexible, as they derive from the access control needs envisaged by the designer of the interface or platform. New functionality such as wasi-virt allows Wasm modules to interpose themselves between the component and the real-world interface, but this cannot be managed dynamically, and it is not yet clear how to specify a requirement that these interposing modules be applied to a particular resource. Linux has similar functionality in the form of seccomp using BPF, but these are too low-level to act as capabilities, and with the filters running in kernel space, these are necessarily more restricted than what can be achieved with Wasm in userspace. Initial TRL 1 Estimated TRL 3 7.5 Integration Across Layers and Use Cases As is explained in Section 7.3, the architecture consists of five core blocks: Orchestration, Isolation, Communication, Monitoring & Detection, and Trust & Access Control. These blocks are instantiated across different layers. These layers represent physical and logical boundaries where components operate and interact, each corresponding to a different level of proximity to data sources and system-wide control. Components in different layers differ in terms of resource availability, network stability, and throughput, and they vary in their impact on the overall system’s performance, reliability, and responsiveness. For ELASTIC, two demonstrators (described in section 7.2.2 and D5.1) and the following three layers are identified: • Edge layer, where lightweight, latency-sensitive components operate close to data sources. Here, Wasm modules execute within isolated runtimes (e.g., TEEs), while eBPF programs enforce real-time network and system policies. • Fog layer, which serves as a mid-tier processing and aggregation point, often hosting orchestrators, AI inference engines, and intermediate decision-making components. Fog computing shifts processing closer to the edge, reducing reliance on the cloud by enabling local decision-making where feasible. It brings compute closer to the data rather than vice versa. • Cloud layer, which provides centralised orchestration, data storage, policy management, and workload migration control, including attestation verification and policy distribution.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 131 - August 31, 2025 Each functional block spans multiple layers, with coordinated responsibilities. For instance, Monitoring & Detection relies on local telemetry collection via eBPF at the edge, aggregated analysis in the fog, and global threat modelling in the cloud. Similarly, Trust & Access Control spans enclave-based isolation at the edge, key distribution in the fog, and attestation authorities in the cloud. The architectural integration is envisioned as a unifying framework across the ELASTIC demonstrators and use cases, aiming to enable secure, responsive, and policy-driven coordination between components operating at different layers. Rather than viewing each component in isolation, the design promotes cross-layer interaction where data flows, control decisions, and trust guarantees are coordinated from edge-level execution to cloud-based orchestration. The goal is to validate how the abstract architecture can flexibly accommodate different deployment models, while maintaining strong security guarantees, policy compliance, and operational resilience in representative 6G-enabled environments. Demonstrator 1 focuses on secure, low-latency orchestration of 6G IoT data fabric services. Wasm modules deployed at the edge process data streams, while eBPF mechanisms monitor resource usage and network behaviour. These components interact with fog-level orchestrators for workload scheduling and offloading decisions, driven by policy enforcement and monitoring feedback loops. Policy enforcement agents ensure that task placement adheres to security constraints (e.g., only moving sensitive data to nodes within certified trust zones). Demonstrator 2 emphasises secure workload migration and trusted execution. Workloads encapsulated as Wasm functions are migrated across heterogeneous infrastructures, with continuous attestation and integrity validation. eBPF programs observe system events during migration, enabling policy compliance tracking. Isolation is maintained through enclavebacked execution across the stack. In both cases, integration across layers ensures that components do not operate in isolation, but rather contribute to a cohesive control and data flow. For example, when a security anomaly is detected at the edge, a signal propagates upward via the Monitoring & Detection and Trust & Access Control blocks, triggering reconfiguration or migration by the Orchestration block. These integration points are explained more concretely in D5.1 in the context of each Demonstrator, and will be further clarified as the project continues. The architecture is intentionally designed to support multiple instantiations, allowing flexible adaptation to evolving technical and operational requirements. The abstract model serves as a blueprint, while demonstrator-specific deployments validate its extensibility and robustness. 7.6 Roadmap and Evolution Although the design of the ELASTIC architecture is considered stable from the perspective of the main functional blocks composing the high-level architecture and their roles, potential improvements are foreseen, especially in regards to the provided services and their capabilities. In fact, the list of components and their capabilities are likely to evolve based on the implementation activities in WP2, WP3, and WP4, especially the components whose developments have not yet started. These evolutions will also be based on the two demonstrators' feedback.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 132 - August 31, 2025 In accordance with the plan, a detailed specification of the components whose implementation was planned for the first period of ELASTIC is delivered in D2.1, D3.1 210 , and D4.1 211 . A first integration of the architecture is also delivered in D5.1. Based on the iterative approach we are following, the detailed specification, interactions, integration, and final implementations of all these components will be delivered in the corresponding deliverables related to the WPs to which each component is associated in the second phase of the project. 210 ELASTIC Project, Lightweight Confidential Computing Platform - Initial version (Deliverable D3.1), to appear 211 ELASTIC Project, Wasm, eBPF and TEE enablement on edge (Deliverable D4.1), to appear
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 133 - August 31, 2025 8 Conclusions and Next Steps The ELASTIC D1.1 presents a comprehensive and forward-looking analysis of the evolving landscape of WebAssembly (Wasm), the WebAssembly System Interface (WASI), and extended Berkeley Packet Filter (eBPF) technologies. These technologies are rapidly becoming foundational pillars for secure, efficient, and portable computing across the cloud–edge–IoT continuum. Through a detailed exploration of their capabilities, limitations, performance characteristics, and security implications, this document lays the groundwork for the ELASTIC’s architectural vision and technical roadmap. The WebAssembly and WASI ecosystem is maturing, capable of complex, distributed workloads. The lightweight, sandboxed execution model, combined with WASI’s evolving system interface standards, offers a compelling alternative to traditional containers and virtual machines, including in resource-constrained environments. The performance benchmarking of Wasm runtimes demonstrates that, with appropriate runtime selection and compilation strategies (e.g., AOT versus JIT), Wasm can achieve near-native performance while maintaining strong isolation guarantees. This positions Wasm as a key enabler for secure, portable execution of federated learning, AI inference, and other latency-sensitive applications at the edge. In parallel, eBPF has emerged as a transformative technology for in-kernel programmability, enabling fine-grained observability, dynamic policy enforcement, and high-performance packet processing. eBPF shows growing adoption across the ecosystem for both networking, observability, performance profiling, and security. The integration of eBPF with orchestration platforms like Kubernetes, and its use in service mesh acceleration, underscores its potential to improve how distributed systems are monitored and secured. However, both Wasm and eBPF introduce new attack surfaces and require robust mitigation strategies. This deliverable shows an initial analysis of known vulnerabilities, threat models, and mitigation techniques, including memory isolation, formal verification, and hardwareassisted protections. It also explains the development of the Pretty Verifier tool and the static eBPF code analyser to improve developer experience and preemptively address security risks. This deliverable also shows initial developments to improve the security of WebAssembly, specifically by introducing Stack Smashing Protections (SSP). The initial version of the ELASTIC architecture, introduced in this deliverable, gives an overview of the components ELASTIC is building to address the shortcomings of the state of the art. It presents a modular, extensible framework. It defines five core building blocks: Orchestration, Isolation, Communication, Monitoring & Detection, and Trust & Access Control. Each block is supported by a suite of innovative components developed by the consortium partners. These components, ranging from lightweight orchestrators and Wasmbased security agents to AI-enhanced intrusion detection systems and hardware-backed attestation services, collectively aim to deliver a secure, scalable, and interoperable platform for next-generation 6G services. This deliverable serves as a foundation for further research and a showcase of the components being developed in WP1, WP2, WP3, and WP4. Within WP1, T1.2 will continue to develop Wasm security improvements, and T1.3 will continue to develop eBPF security tools.
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 134 - August 31, 2025 9 Annex - ELASTIC Component Specification Form This annex provides the template used to collect and structure information on ELASTIC components for the development of the project architecture. The form ensured consistency in documenting each component’s ownership, scope, and relevance across WPs and demonstrators, thereby supporting the design of the first version of the ELASTIC architecture. Table 32: ELASTIC Component Specification Template. Component Name Enter the full name of the component Component Owner Indicate the partner or organisation responsible for developing and maintaining this component Relevant WPs List the work packages (WP) this component contributes to Relevant Demonstrator Specify which demonstrator(s) this component is part of Type Define the type of component Description Provide 1–2 paragraphs: Component Purpose and Role: What does the component do? How does it contribute to the overall system in ELASTIC? Added Value & Innovations 1 paragraph: Is this a new component or do you plan to extend this component as part of ELASTIC: what specific features or functionalities will you add or improve? Progress Beyond the SOTA 1 paragraph: How does this component advance beyond the current SOTA? What are the existing limitations it addresses, and how does it differ from similar components?) Initial TRL Specify the initial TRL before ELASTIC project Estimated TRL Estimate the expected TRL after integration and testing within ELASTIC Licensing Licensing scheme / related considerations of component & underlying technologies Main Inputs - Input #1 Specify main inputs, data or APIs Input Source Sspecify from which component data will be used as input Format of Expected Input/Interfaces Indicate the input format that your component would expect (e.g. JSON, image files, ect) and/or connection interfaces - APIs Triggered by Indicate the events or conditions that trigger the component's functionality Main Inputs - Input #2 Specify main inputs, data or APIs Input Source Specify from which component data will be used as input Format of Expected Input/Interfaces Indicate the input format that your component would expect (e.g. JSON, image files, ect) and/or connection interfaces - APIs Triggered by Indicate the events or conditions that trigger the component's functionality Main Outputs - Output #1 Specify main outputs, data or APIs Output Destination Indicate the partner you will be getting data from Format of Expected Output/Interfaces Indicate the output format that your component would be expected to produce (e.g. JSON, image files, etc.) and/or connection interfaces - APIs Triggered by Indicate the events or conditions that trigger the component's functionality
ELASTIC D1.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 135 - August 31, 2025 Main Outputs - Output #2 Specify main outputs, data or APIs Output Destination Indicate the partner you will be getting data from Format of Expected Output/Interfaces Indicate the output format that your component would be expected to produce (e.g. JSON, image files, etc.) and/or connection interfaces - APIs Triggered by Indicate the events or conditions that trigger the component's functionality Main functional Requirements Define the main functional requirements of your component Main non-functional Requirements Define the main non-functional requirements of your component Software Platform Requirements Specify any SW requirements or dependencies or containerisation requirements Hardware Platform Requirements Specify the minimum HW required for the best functionality of the component