ELASTIC D1.2: Security of Wasm and eBPF Technologies

Horizon Europe Framework Programme HORIZON JU Research and Innovation Action Reliable Services and Smart Security Efficient, portabLe And Secure orchesTration for reliable servICes D1.2: Security of Wasm and eBPF Technologies Abstract: Executable isolation is a key ingredient to the ELASTIC framework, allowing the safe and efficient execution of untrusted software in an isolated environment. In this document, we examine the security landscape of ELASTIC's two main executable isolation technologies, Wasm and eBPF, identifying and mitigating potential vulnerabilities, as well as presenting new technologies that will help to secure users' applications, protect the platform from malicious software, enable robust and secure orchestration of Wasm applications, ease development of secure eBPF software, and monitor running systems for potential intrusions with a greater level of performance and observability than the current state of the art. Contractual Date of Delivery 30/11/2025 Actual Date of Delivery 06/12/2025 Deliverable Security Class Public Editor Lachlan GUNN (AAL) Contributors AAL, ERF, LUN, POLITO, THD, THS, TUC, UVC, ZEN Internal Reviewers Miika Komu, Jimmy Kjallman, Amine Boukhtouta (ERF) Fionn Mc Inerney (TID) ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 2 - November 30, 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 IMEC 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 3 - November 30, 2025 Document Revisions & Quality Assurance Internal Reviewers 1. Miika Komu, Jimmy Kjallman, Amine Boukhtouta, ERF 2. Fionn Mc Inerney, TID Revisions Version Date By Overview 1.0 06/12/2025 TUC Comments and approval from the PC 0.9 06/12/2025 TUC Quality check 0.8 04/12/2025 TID, ERF Approval from the IRs and STM 0.7 02/12/2025 THS Comments on the 2nd draft from STM 0.6 28/11/2025 Lachlan Gunn, All contributors 2nd draft 0.5 27/11/2025 TID, ERF Comments on the 1st draft 0.4 20/11/2025 Lachlan Gunn First draft 0.3 18/11/2025 All contributors Input received 0.2 07/11/2025 TUC, THS Comments on the TOC 0.1 04/11/2025 Lachlan Gunn 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 4 - November 30, 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 WEBASSEMBLY ....................................................................................................................................... 14 2.1 THE STATE OF THE ART ........................................................................................................................ 14 2.1.1 WebAssembly Execution and Security Model ................................................................................. 14 2.1.2 Known Vulnerabilities and Limitations .......................................................................................... 15 2.1.3 Security Enhancements and Future Outlook .................................................................................. 16 2.2 WEBASSEMBLY SANDBOX SECURITY .................................................................................................. 16 2.2.1 Memory safety ................................................................................................................................ 17 2.2.2 Side-channel attacks on Wasm code ............................................................................................... 19 2.2.2.1 Side-channel attacks on confidential WebAssembly code in Trusted Execution Environments ......... 20 2.2.3 Formal verification & testing ......................................................................................................... 21 2.3 WEBASSEMBLY INTERFACE SECURITY................................................................................................. 23 2.3.1 WASI interface security .................................................................................................................. 24 2.3.1.1 Syscall isolation through virtualisation ................................................................................................. 25 2.3.1.2 Isolation through system call interception and validation .................................................................... 26 2.3.1.3 Isolation through typed interface contracts ........................................................................................... 27 2.3.2 Randomness .................................................................................................................................... 28 2.3.3 Filesystem ....................................................................................................................................... 29 2.3.4 Network........................................................................................................................................... 30 2.3.5 Hardware accelerators ................................................................................................................... 32 2.3.6 Sensors ............................................................................................................................................ 33 2.3.7 Cryptographic Resources ............................................................................................................... 34 2.3.8 Custom access control .................................................................................................................... 35 2.3.8.1 Performance evaluation......................................................................................................................... 35 2.3.8.2 Limitations ............................................................................................................................................ 40 2.4 SECURITY OF WASM APPLICATIONS DURING ORCHESTRATION AND MIGRATION ................................. 40 2.4.1 Wasm application identity .............................................................................................................. 41 2.4.2 Security of Wasm migration ........................................................................................................... 46 2.5 PROPOSALS AND RECOMMENDATIONS ................................................................................................. 49 3 EBPF ............................................................................................................................................................ 51 3.1 EBPF/XDP SECURITY INVESTIGATION ................................................................................................. 51 3.1.1 Systematic literature review ........................................................................................................... 51 3.1.2 Analysis of eBPF-related CVEs ...................................................................................................... 54 3.1.3 Study of the exposure of eBPF C-code to security vulnerabilities ................................................. 57 3.1.4 Threats, vulnerabilities, attack surfaces, and exploitation techniques........................................... 57 3.1.5 Mitigation Techniques .................................................................................................................... 58 3.1.6 Final considerations, best practices, and recommendations ......................................................... 61 3.2 EBPF/XDP FOR ENHANCING NETWORK SECURITY AND LOW LATENCY ............................................... 62 3.2.1 eBPF for acceleration of microservice-to-microservice communication....................................... 62 3.2.2 Service mesh performance assessment ........................................................................................... 63 3.2.3 eBPF deployment performance evaluation .................................................................................... 67 3.2.4 Proposals and recommendations to overcome current limitations and to increase performance . 69 3.2.4.1 A proposal for using eBPF to accelerate end-to-end TCP performance on local connections ............. 69 3.2.4.2 Recommendations for improving eBPF deployment performance....................................................... 71 3.3 STATIC EBPF CODE SECURITY ANALYSIS ............................................................................................. 72 3.3.1 Motivation and problem statement ................................................................................................. 72 3.3.2 Requirements .................................................................................................................................. 72 3.3.3 State of the art, methodology, and design ...................................................................................... 73 3.3.4 Implementation ............................................................................................................................... 75 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 5 - November 30, 2025 3.3.5 Testing ............................................................................................................................................ 76 3.4 EBPF-BASED IDS ................................................................................................................................. 79 3.4.1 eBPF-based traffic capture ............................................................................................................ 79 3.4.2 Hardware AI-based IDS solutions.................................................................................................. 83 3.5 PROPOSALS AND RECOMMENDATIONS ................................................................................................. 86 4 CONCLUSIONS AND NEXT STEPS ...................................................................................................... 89 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 6 - November 30, 2025 List of Tables Table 1: Side-channels collected for study. ........................................................................................... 21 Table 2: Instantiation performance. ....................................................................................................... 38 Table 3: Function invocation overhead .................................................................................................. 40 Table 4: Classification of output messages in the eBPF verifier code. .................................................. 73 Table 5: Measured TCP throughput when intercepting loopback traffic with different capture solutions. ................................................................................................................................................................ 83 Table 6: Preliminary performance evaluation results of the ELASTIC framework integrating eBPF with the AI-based IDS pipeline. ..................................................................................................................... 86 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 7 - November 30, 2025 List of Figures Figure 1. Benchmark component configurations. .................................................................................. 36 Figure 2. Instantiation overhead distributions. (a) Two-component baseline configuration, (b) Threecomponent shimmed configuration. ....................................................................................................... 38 Figure 3. Instantiation overhead distributions. (a) Two-component baseline configuration, (b) Threecomponent shimmed configuration. ....................................................................................................... 39 Figure 4. Example of the instantiation graph of an application that includes a library as a dependency. The verifiers can extract the subgraph containing the instantiation graph of the library and check it against the hash of the library loaded in isolation. ................................................................................. 44 Figure 5. Example of the composition of components in an application. .............................................. 45 Figure 6. Workflow of fair component migration in ideal case. ............................................................ 48 Figure 7. Workflow of fair component migration in ideal case. ............................................................ 49 Figure 8. Temporal distribution of eBPF CVE entries. ......................................................................... 55 Figure 9. Number of eBPF CVEs affecting the initial release of each Linux kernel minor version. .... 55 Figure 10. Number of eBPF CVEs by category (i.e., module). ............................................................. 56 Figure 11. Analysis of severity and exploitation characteristics of eBPF CVEs. .................................. 56 Figure 12. Comparison of host-local iperf3 network throughput between a TCP baseline (orange) and TCP over an SK_MSG transport (blue). ................................................................................................. 63 Figure 13. Measured throughput (top) and latency (bottom) under multiple service mesh combinations. ................................................................................................................................................................ 66 Figure 14. Comparative latency and throughput measurements of network policies enforcement using eBPF in Calico and Cilium. ................................................................................................................... 68 Figure 15. Proposed high-level data path for TCP communications across containers sharing the same Linux kernel (red), compared to the current typical message journey in the same conditions (blue). .. 70 Figure 16. Proposed control plane for our TCP-bypass technique. ....................................................... 70 Figure 17. The two approaches considered for the design of the analyser. ........................................... 74 Figure 18. Examples of output of the Pretty Verifier analyser. ............................................................. 76 Figure 19. Results of the tests on the Pretty Verifier analyser. .............................................................. 79 Figure 20. 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. While the figure only represents outbound traffic, received messages go through largely the same stack and are intercepted in equivalent positions. ................................................................................................................................................ 80 Figure 21. ELASTIC tool integrating eBPF and AI-IDS for 6G network vulnerability mitigation. ..... 85 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 8 - November 30, 2025 List of Abbreviations AES-CTR Advanced Encryption Standard, Counter Mode AI Artificial Intelligence AI-IDS AI-enhanced Intrusion Detection System ALU Arithmetic Logic Unit API Application Programming Interface ARM Advanced RISC Machines ASLR Address Space Layout Randomisation BPF Berkeley Packet Filter BSD Berkeley Systems Distribution BTF BPF Type Format CFI Control-Flow Integrity CHC Constraint Horn Clauses CI Continuous Integration CLI Command-Line Interface CNI Container Network Interface CNN Convolutional Neural Network CPU Central Processing Unit CSP Cloud Service Provider CVE Common Vulnerability Enumeration CVSS Common Vulnerability Scoring System CWE Common Weakness Enumeration DDoS Distributed Denial of Service DNS Domain Name System DoS Denial of Service Dx.x Deliverable x.x eBPF Not an acronym. EC European Commission ECDH Elliptic-Curve Diffie-Hellman ELASTIC Efficient, portabLe And Secure orchesTration for reliable servICes EPF Evil Packet Filter FPGA Field-Programmable Gate Array GPIO General-Purpose Input/Output GPL General Public Licence GPU Graphics Processing Unit HAL Hardware Abstraction Layer HTTP Hypertext Transfer Protocol I/O Input/Output I²C Inter-Integrated Circuit protocol ID Identifier IDS Intrusion Detection System ISLE Instruction Selection Lowering Expressions IPC Inter-Process Communication IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 JIT Just-In-Time [compilation] KPI Key Performance Indicator LAN Local-Area Network ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 9 - November 30, 2025 LKNS Linux Kernel Network Stack LLVM Not an acronym. LSTM Long Short Term Memory LTS Long Term Support Lx [OSI] Layer x MAC Medium Access Control NAT Network Address Translation NPU Neural Processing Unit NTFS NT File System NUMA Non-Uniform Memory Access NVD National Vulnerability Database OS Operating System PCI Process Context Identifier PKS [Intel] Protection Key Supervisor POSIX Portable Operating System Interface RAM Random Access Memory ROP Return-Oriented Programming RP Reporting Period RQ Research Question RSA Rivest-Shamir-Adler SAT Boolean SATisfiability problem SEV [AMD] Secure Encrypted Virtualisation SEV-SNP [AMD] Secure Encrypted Virtualisation, Secure Nested Paging SFI Software Fault Isolation SGX [Intel] Software Guard Extensions SLR Systematic Literature Review SPI Serial Peripheral Interface SSP Stack Smashing Protection TCB Trusted Computing Base TCP Transmission Control Protocol TCX Not an acronym. TEE Trusted Executed Environment TLS Transport-Layer Security TOCTOU Time-Of-Check-To-Time-Of-Use TPU Tensor Processing Unit TTP Trusted Third Party Tx.x Task x.x UDP User Datagram Protocol URL Uniform Resource Locator USB Universal Serial Bus VM Virtual Machine WAC WebAssembly Compositions WAMR WebAssembly Micro Runtime WAN Wide-Area Network WASI WebAssembly System Interface Wasm WebAssembly WAT WebAssembly Text format Winsock Windows Sockets WIT WebAssembly Interface Types ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 16 - November 30, 2025 2.1.3 Security Enhancements and Future Outlook In response to emerging threats and practical limitations of the Wasm execution model, recent research has focused on enhancing its security guarantees across multiple fronts. These efforts span both software and hardware-level solutions, aiming to bridge the gap between performance, portability, and secure execution. To address limitations in memory safety, studies have explored hardware-assisted mechanisms, such as memory tagging and pointer authentication, to offer fine-grained isolation that complements the existing linear memory model 10 . In parallel, integration with Trusted Executed Environments (TEEs) has emerged as a promising direction, enabling Wasm modules to execute within secure enclaves, thereby protecting them from potentially compromised host environments 11 . Additionally, recent research 12 , 13 , 14 has introduced advanced fuzzing and analysis frameworks that leverage structure-aware and semantics-guided techniques to detect logic flaws, miscompilations, and runtime violations in Wasm binaries. As Wasm continues to expand beyond browsers into serverless and edge platforms, research increasingly emphasises resource control, policy enforcement, and safe multitenancy in these contexts 15 . Concurrently, efforts by the Bytecode Alliance and W3C aim to standardise secure modular composition through the Wasm Component Model 16 and WASI, promoting capability-based access control and type-safe linking of modules as best practices for scalable and secure deployment. 2.2 WebAssembly Sandbox Security WebAssembly executes untrusted code inside a software sandbox that provides strong memory and control-flow isolation from the host. The principal security objective is to prevent a WebAssembly module from accessing or modifying memory or resources outside its assigned domain. Unlike native binaries, Wasm modules operate on a structured instruction set without arbitrary pointers; all indirect control-flow transfers are type-checked, and linear memory is bounded, ensuring that modules cannot jump into arbitrary code or overwrite host memory. These are then translated by the compiler to native code in such a way that at runtime, callframe metadata, return addresses, and registers are held outside the module’s linear memory, significantly reducing the risk of classical corruption-based attacks such as return-oriented programming. Thus, the sandbox protects the host from the module, enabling secure execution of potentially adversarial logic. However, this isolation introduces several trade-offs. First, sandboxing restricts module visibility into runtime and hardware features that would otherwise be available to native binaries. Capabilities such as direct system calls, filesystem traversal, device access, and highprecision timers are not accessible by default and must be explicitly exposed through WASI or custom host interfaces. While the absence of ambient authority minimises the risk of unintended privilege escalation, it also requires explicit capability management by the host. Since the memory safety guarantees of the sandboxed are enforced by the compiler, which generates code that is inherently unable to write outside of its assigned memory space, this makes the Wasm compiler a key part of the system's TCB. This strongly incentivises the use of JIT or other techniques that allow compilation to take place within the host that will ultimately execute the code. We might use AOT compilation to relieve the host of this additional work; 10 M. Fink, D. Stavrakakis, D. Sprokholt, S. Chakraborty, and J.-E. Ekberg, “Cage: Hardware-Accelerated Safe WebAssembly,” Proc. ACM SIGPLAN Conf. Programming Language Design and Implementation (PLDI), 2025. 11 J. Ménétrey, M. Pasin, P. Felber, and V. Schiavoni, “Twine: An Embedded Trusted Runtime for WebAssembly,” arXiv preprint arXiv:2103.15860, 2021. 12 J. Wang, Z. Guo, X. Ying, P. Qian, and Y. Chen, “SwFuzz: Structure-Sensitive WebAssembly Fuzzing,” Asia–Pacific Software Engineering Conference (APSEC), 2024. 13 H. Chen, Y. Liu, M. Xu, and L. Zhang, “WasmCFuzz: Structure-Aware Fuzzing for Wasm Compilers,” International Conference on Compiler Construction (CC), 2023. 14 X. Cao et al., “Wapplique: Testing WebAssembly Runtime via Execution Context-Aware Bytecode Mutation,” Proc. Int. Symp. Software Testing and Analysis (ISSTA), 2024. 15 J. Zhu, Y. Xia, and Z. Huang, “Enabling Serverless Edge Computing with WebAssembly,”Proc. 2021 IEEE Intl. Conf. on Edge Computing (EDGE), 2021, pp. 136–143. 16 https://component-model.bytecodealliance.org/ ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 17 - November 30, 2025 however, this necessitates the introduction of a trustworthy software distribution mechanism to allow code to be safely distributed from the compiler to the host, and does not eliminate the compiler as a potential attack surface, since the compiler generates code that runs on the host system without further checks. Furthermore, WebAssembly’s linear memory model lacks address space layout randomisation (ASLR) within the sandbox itself. Unlike native binaries, where ASLR probabilistically randomises stack, heap, and code layouts to hinder exploitation, WebAssembly organises its linear memory deterministically, and stack and heap positions are predictable from the compiler output. As discussed by Lehmann et al. 17 , even if ASLR were added, 32-bit linear memory addressing would offer insufficient entropy for strong protection. This deterministic layout simplifies verification and reproducibility, but may also facilitate certain memory-probing or information-leakage techniques. Finally, the additional layer of indirection between the module and host resources can introduce moderate performance overhead compared to native execution, particularly when frequent host calls or I/O operations are involved. Despite its security guarantees, the sandbox is not impervious to exploitation. If a Wasm module is compiled from memory-unsafe languages, traditional bugs such as buffer overflows 18 , 19 or heap corruption may arise within the module’s linear memory. While these cannot escape into host memory, they can enable internal corruption, including manipulation of function-table indices to redirect indirect calls. Such attacks can support limited control-flow hijacking within sandbox boundaries. Moreover, side-channel attacks remain a significant class of bypass techniques. Adversaries can infer sensitive information, such as cryptographic key material, through timing analysis, cache-access patterns, or speculative-execution leakage, bypassing software isolation even if the logical sandbox remains intact. These limitations emphasise the need for complementary defences such as TEE integration, side-channel-resistant primitives, and strict capability mediation policies. 2.2.1 Memory safety In order to improve protection against memory attacks in Wasm, we assessed the various ways we can leverage protection mechanisms available in native binaries and adapt them to Wasm. Based on the work by Lehmann et al., we focused our efforts on Stack Smashing Protection (SSP). 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 securitysensitive applications. 17 D. Lehmann, J. Kinder, i M. Pradel, “Everything Old is New Again: Binary Security of WebAssembly,” u Proc. 29th USENIX Security Symposium (USENIX Security ’20), aug. 2020, str. 217-234, USENIX Assoc. 18 Minseo Kim, Hyerean Jang, and Youngjoo Shin. Avengers, assemble! Survey of WebAssembly security solutions. In 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), pages 543–553, 2022. doi: 10.1109/CLOUD55607.2022.00077. 19 Hakon Harnes and Donn Morrison. Sok: Analysis techniques for webassembly. Future Internet, 16(3):84, February 2024. ISSN 19995903. doi: 10.3390/fi16030084. URL http://dx.doi.org/10.3390/ fi16030084 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 18 - November 30, 2025 This subsection presents ELASTIC’s hardened implementation of Stack Smashing Protection 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 and recommended its introduction in Wasm compilation toolchains. Although a basic SSP mechanism has since been introduced in LLVM-based toolchains for standalone WebAssembly binaries, it has not undergone an in-depth security validation. The following ELASTIC work sought to determine whether this protection was effective in practice and to strengthen it where necessary. It resulted in a paper that was presented at the PLAS 2024 workshop 20 and accepted at FNWF 2024 21 in a shorter version. 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 (wasmtime, wasmedge, wasmer, iwasm (WAMR), wasm3 and wasmi) 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 22 . 20 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. 21 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 22 https://github.com/ThalesGroup/llvm-project/tree/new-wasm-ssp ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 19 - November 30, 2025 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. 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. 2.2.2 Side-channel attacks on Wasm code The feasibility of physical side-channel attacks depends on physical proximity to the target machine. Contrary to those, microarchitectural attacks can be performed by executing code on the target machine. Cache attacks are a category of microarchitectural side-channel attacks that enable precise monitoring of memory access patterns by exploiting differences in memory access timing. When memory sits in the CPU cache it is much faster accessed compared to when fetching data in main memory. Such timing differences open up the possibility of cache-based side-channels. The attacker first loads a cache line with their own data, then waits for the victim to execute, potentially evicting or modifying that cache line. By subsequently measuring the access time to the cache lines, the attacks can infer which part of memory the victim process is accessing and extract sensitive information such as cryptographic keys, website-browsing fingerprints, keystrokes, etc. This risk is especially prevalent in portable code executed in browsers, such as JavaScript and WebAssembly. When a web browser loads a website, the included JavaScript and WebAssembly modules are loaded and executed on to the browsers machine. Genkin et al. 23 demonstrated how malicious Web content could, via portable code like WebAssembly and NaCl, extract ECDH, RSA and ElGamal secret cryptographic keys by launching a cache attack in a browser-based setting. More recently, Katzman et al. 24 showed that transient-executionbased techniques can amplify cache state signals significantly, allowing eviction set creation and cache sampling even when the attacker only has coarse-resolution timers of 0.1ms. Due to the severity of these attacks, web browsers and runtime environments have introduced restrictions on high-precision timers and features like SharedArrayBuffer. High precision timers or features such as SharedArrayBuffers have been disabled or limited in many browsers to reduce attacker timing accuracy. However, portable code can implement their own counters as a means to get accurate timing measurements. Mazaheri et al. 25 were able to build a timer with nanosecond-level accuracy using a WebAssembly module and shared memory. This work used a simple counter in shared memory which another JavaScript was able to use as a timer 23 Genkin, Daniel, Lev Pachmanov, Eran Tromer, and Yuval Yarom. "Drive-by key-extraction cache attacks from portable code." In Applied Cryptography and Network Security, ACNS 2018, Leuven, Belgium, July 2-4, 2018 (16), pp. 83-102. Springer International Publishing, 2018. 24 Katzman, Daniel, William Kosasih, Chitchanok Chuengsatiansup, Eyal Ronen, and Yuval Yarom. "The gates of time: Improving cache attacks with transient execution." USENIX Security Symposium (USENIX Security 23), pp. 1955-1972. 2023. 25 Mazaheri, Mohammad Erfan, Siavash Bayat Sarmadi, and Farhad Taheri Ardakani. "A Study of Timing Side-Channel Attacks and Countermeasures on JavaScript and WebAssembly." ISeCure 14.1 (2022). ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 20 - November 30, 2025 for cache based side-channel attacks. WebAssembly being more low-level than JavaScript and using pre-compiled modules also meant that the timing measurements were more consistent. Mitigations for cache-based side-channel attacks are difficult to implement without significant negative impact on the system performance. Mazaheri et al. 2022 includes a comprehensive list of countermeasurements implemented on different levels, from hardware to OS and browser level. Isolated or exclusive cache memory for processes is suggested, but that requires special hardware which cannot be expected from all systems. Timing countermeasurements have already been implemented in browsers, but value counters reduce the effectiveness of these methods. Due to the reduced performance introduced by the mitigations, the paper instead focuses on detection, by scanning the portable code of malicious features, which could implement a cache based side-channel attack. They presented “Lurking Eyes” to scan web pages and achieved a 99.8% accuracy over a set of 3350 malicious or benign web pages. They had no cases of false negatives - meaning that no malicious pages were undetected. 2.2.2.1 Side-channel attacks on confidential WebAssembly code in Trusted Execution Environments While the previous section focused on browser-based WebAssembly attacks, a very different threat model emerges when WebAssembly is executed inside Trusted Execution Environments (TEEs). Cloud providers increasingly rely on TEEs such as Intel SGX and AMD SEV to offer confidential computing, where code and data are encrypted to protect tenants from a potentially malicious hypervisor. SGX protects a single application through enclave-based memory encryption, whereas SEV encrypts the entire virtual machine used by the guest. Despite these protections, both platforms have been shown to leak information through microarchitectural side channels. Puddu et al. 26 demonstrated that executing WebAssembly inside SGX increases side-channel leakage, enabling recovery of confidential code through instruction fingerprinting. Their evaluation focused solely on SGX, but the underlying issue - fine-grained leakage from interpreter behaviour - extends to other TEEs as well. Within ELASTIC, we have performed a similar attack on AMD SEV using the SEV-Step framework. Our attack has been performed on the WebAssembly runtime WAMR. The modules were loaded and executed by the iwasm classic interpreter. The attack is then performed in two phases: first, a profiling phase where side-channel measurements are collected during a known execution. Then an attack phase where we measure the traces of the victim executing an unknown WebAssembly module in the same runtime and match the traces to our known execution. Data collection is done by single-stepping the machine once the iwasm classic interpreter has started executing. This single-stepping operates at the machine-instruction level rather than the WebAssembly instruction level. As a result, a single WebAssembly instruction like WASM_OP_I32_ADD takes roughly eight x86 instructions to perform, resulting in a trace of eight different side channel measurements collections. After each step, we revoke access rights to all the victim memory pages. When we resume execution of the victim machine, a page fault will be raised, revealing both the memory location accessed and whether the access was a read (R), write (W) or instruction fetch (E). The latency of the x86 instruction is collected by measuring the time of performing a single step. Table 1 below summarises the side-channels we collect and the method used. 26 Puddu, Ivan, et al. "On (the lack of) code confidentiality in trusted execution environments." 2024 IEEE Symposium on Security and Privacy (SP). IEEE, 2024. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 21 - November 30, 2025 Table 1: Side-channels collected for study. Side-channel Method Latency [Numerical] Single-stepping Memory Page [0xAAAB000] Page Faults Access Type [R/W/E] Page faults After data collection, we also extracted memory location of important variables used in the WAMR runtime. The interpreter’s lookup table, which identifies the handler for the next WebAssembly instruction, is always accessed with a read followed by a JMP. In the sidechannel trace, this means that the read instruction is followed by an execute type of instruction. Keeping this in mind, it is possible to extract the memory location of the lookup table solely based on memory access patterns. The lookup table address would then reveal when new WebAssembly instructions were fetched in the iwasm runtime. Subsequently, the memory region acting as the WebAssembly stack can be extracted by identifying recurring read/write patterns. To match the side-channel data to WebAssembly instructions, we wrote a .WAT script which executes all the instructions in the MVP of WebAssembly 1.0. The collected traces of sidechannels were then matched to different WebAssembly instructions, creating a database of collected fingerprints. We also compiled some WebAssembly modules from some simple C code to further increase the size of our fingerprints database. The attack phase consists of first collecting a trace of side-channels extracted when a victim runs a WebAssembly module. The stack pointer memory location and lookup table would then be extracted by analysing the data. Then the trace would be matched to the database of fingerprints using correlation of latencies and hamming distances of other side-channels to reconstruct the list of executed WebAssembly traces. The previous work by Puddu et al. 2024 closely resembles our attack, performed in Intel SGX. Their attack also single-stepped the victim but did not use memory locations as a side channel for their attack. The matching method was based on using regex expressions to match instructions to their extracted trace. In their works, they were able to reconstruct about 28% of the instructions when studying the interpreter phase of the WAMR runtime, and about 46-50% in the loader phase. Our attack significantly outperformed their result, achieving 67-78% perfect reconstruction in the interpreter phase alone. The ELASTIC D2.2 report 27 also presents a study on confidentiality in WebAssembly runtimes being executed in Intel SGX. There, TID demonstrates that syscall patterns alone can reveal embedded components such as SQL engines. Their work differs from ours in that it relies on system-call observability rather than fine-grained memory-access reconstruction, but it similarly highlights the susceptibility of WebAssembly runtimes to side-channel analysis. Future work includes exploring mitigations and evaluating cache-based side-channels in the context of code confidentiality. 2.2.3 Formal verification & testing The isolation properties of a Wasm runtime are necessarily conditional on its correct implementation, and thus considerable effort has been spent ensuring this. Here, we examine techniques used to ensure the correct implementation of Wasm sandboxes. One safety guarantee of Wasm is sandboxing isolation. To achieve this isolation, a compiler or interpreter needs to insert safety checks when it compiles or interprets Wasm. By doing this, 27 ELASTIC Project, Serverless FaaS with Lightweight Containers (Deliverable D2.2), Zenodo, 2025. doi: 10.5281/zenodo.17590937 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 22 - November 30, 2025 trust has been put on the compiler or interpreter. They are expected to insert every necessary check formally correct and at the proper place. Once they fail to meet this expectation, isolation can be broken. Verified compilers enforce memory isolation. vWasm and rWasm are popular open-source tools that employ different techniques for provably secure compilers through formal validation without sacrificing efficiency. vWasm utilises mathematically formal methods to prevent compiled Wasm code from jumping to prohibited memory location in the host. rWasm follows a different approach by leveraging Rust’s safety guarantee, hence, providing safety compilation without explicitly asking for proofs from developers. These tools eliminate an attack vector of control-flow hijacking within a sandbox and data corruption causing sandbox escapes. MSWasm 28 is another formally verified compiler that guarantees memory safety of a program based on coloured memory locations and pointers. This compiler proposes a new memory region called segment, whose offsets cannot be arbitrarily accessible through standard instructions such as load and store. Instead, this segment is safely accessible and the memory allocation can be enforced through new types, values, and regulated instructions. Crocus is not a verified compiler itself but a lightweight framework targeting a specific compiler only, Cranelift. The framework found two unknown bugs on arm64 architecture by modularly verifying Wasm-to-Native Instruction Selection. Instruction Selection Lowering Expressions (ISLE) has been introduced by the compiler and it can express instruction lowering patterns for target architectures. For interpreters that insert safety checks when interpreting in Wasm, those interpreters can also be verified to guarantee their implementation does not contain bugs. WasmRef-Isabelle is a fully verified, efficient new monadic interpreter for Wasm, that has been adopted and deployed as a fuzzing oracle for Wasmtime runtime. WasmRef-Isabelle uses different control flow representation and replaces inefficient list-based state representations in Wasm specification with arrays and monadic state in varied places. There have been several attempts to verify the safety of sandboxed codes with binary verification. If all Wasm binaries compiled by a compiler are fully sandboxed, a compiler can be trusted to be correct. If not, bugs of the compiler implementation can be revealed and fixed by examining binaries that are not well-sandboxed. VeriWasm 29 is a static offline verifier targeting x86_64 binary compiled from Wasm. The verifier does not verify the compiler, instead, it verifies memory isolation of Wasm binaries at the post-compilation stage. VeriWasm verifies the isolation and safety of four local properties of the Wasm module: linear memory, stack, global variable, and control flow. Solely enforcing strong memory isolation with Wasm binaries verification, verified Wasm compilers and interpreters, and fuzzing techniques appliances on Wasm compilers is not enough. Challenges with implementing WASI interfaces that runtimes must deal with are not only memory isolation, but also resource isolation enforcement, including file system and network isolation Hence, WaVe, 30 a mechanically-verified runtime that offers appealing performance against other existing unsafe Wasm runtimes in the industry, has been developed and introduced. Untrusted code implementing WaVe is verified with Prusti, a prototype verifier written in Rust, which formally proves code contracts are correct and do not contain software bugs, while trusted specification and OS specification code has been fuzzed for correctness and vulnerability-exempted confirmation. 28 Alexandra E. Michael, Anitha Gollamudi, Jay Bosamiya, Evan Johnson, Aidan Denlinger, Craig Disselkoen, Conrad Watt, Bryan Parno, Marco Patrignani, Marco Vassena, and Deian Stefan, "MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code". Proceedings of the ACM on Programming Languages. 7(POPL), 2023. https://doi.org/10.1145/3571208 29 Johnson, Evan, et al. "Доверяй, но проверяй: SFI safety for native-compiled Wasm." Network and Distributed Systems Security (NDSS) Symposium. 2021. 30 Johnson Evan, Evan Laufer, Zijie Zhao, Dan Gohman, Shravan Narayan, Stefan Savage, Deian Stefan, and Fraser Brown, WaVe: a verifiably secure WebAssembly sandboxing runtime. 2023. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 23 - November 30, 2025 Despite this significant progress in formal verification of Wasm runtimes, no mainstream runtime has yet been formally verified. However, testing frameworks can serve a similar purpose of identifying implementation errors in Wasm runtimes, even if they cannot provide the strong guarantees of formal verification. Moreover, formal verification is only as useful for this purpose as the underlying model of the Wasm ISA is correct. Fuzzing techniques can address those existing limitations, hence, generating broader test case coverage and detecting unknown vulnerabilities in Wasm runtimes. RGFuzz 31 is a fuzzing tool that leverages ruleguided fuzzing techniques to extract compilation rules from runtimes and applies reserve stackbased generation to diversely generate additional test cases. RGFuzz has been evaluated on multiple engines, including well-known industrial runtimes such as Wasmtime, Wasmer, and WasmEdge. WASMaker 32 is a testing framework that can reveal hidden inconsistent issues among Wasm runtimes through generating complicated Wasm binaries as test cases. Wasmmaker also includes a runtime-agnostic root cause location where bugs can be found precisely. As a result, the framework uncovered 33 unique bugs in Wasm runtimes. Wasm runtimes need to implement WASI in order to let Wasm programs interact with their surrounding environment. Those programs require system calls and host calls with the OS environment and accessing resources from a system level. Wasm runtimes stand as a bridge between the communication of sandboxing Wasm programs and untrusted OS. Formally verifying the robustness of this bridge is critical and challenging. With a lack of proper verification, program flaws can escape the sandbox and spread to the OS, or data that is supposed to be only located inside the Wasm bytecode internally can still be exfiltrated. DrWASI 33 is a differential testing framework based on Large Language Models which comprises around 4500 Wasm binaries. The group of authors claimed that nearly all WASI functions have been covered within those binaries. The test suite has been tested with Wasmer, Wasmtime, WasmEdge, and WAMR, and detected 33 previously-unknown WASI bugs, as well as several cases of differing interpretations of the WASI standards that led to inconsistent implementations. Despite their weaker guarantees in comparison with formal verification, these testing-based methodologies lead to them holding significantly greater value to the ELASTIC framework; formal verification requires the use of specialised runtimes designed with verification in mind that do not necessarily support the latest features of Wasm, and whose improvement yields limited impact on industry and the open-source community. Conversely, testing frameworks can be applied more easily to arbitrary runtimes, allowing us to benefit from their ability to detect implementation errors in mainstream runtimes like Wasmtime and WAMR that are a better fit for the requirements of ELASTIC. This allows us to be confident in the strength of their sandboxing and memory safety guarantees. 2.3 WebAssembly interface security A critical part of evaluating Wasm isolation is analysing the security of host functions (similar to syscalls) exposed through the WASI interface. To perform useful tasks, 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 31 Park, Junyoung, Yunho Kim, and Insu Yun. "RGFuzz: Rule-Guided Fuzzer for WebAssembly Runtimes." 2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025. 32 Cao, Shangtong, et al. "Wasmaker: Differential testing of webassembly runtimes via semantic-aware binary generation." Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 2024. 33 Yixuan Zhang, Ningyu He, Jianting Gao, Shangtong Cao, Kaibo Liu, Haoyu Wang, Yun Ma, Gang Huang, and Xuanzhe Liu, DrWASI: LLM-assisted Differential Testing for WebAssembly System Interface Implementations, ACM Transactions on Software Engineering and Methodology. 2025. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 24 - November 30, 2025 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 of underlying platform differences. Moreover, data transfer to or from a module requires access to the module's memory, limiting the ability to compose mutually-distrusting modules with one another. 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, and allow data to be transferred by the runtime in a standard manner that does not compromise the security of the sandbox. Components use WIT (WebAssembly Interface Types) to specify language-agnostic interface contracts, explicitly declaring input and output data types without dependencies on hostspecific implementations. WASI 0.2 defines a system interface using WIT, including a capability-based security model where hosts grant granular resource permissions (e.g., file system access or network connections) in the form of opaque “resource” types with standardised interfaces, rather than directly exposing the underlying system calls. This architecture achieves true write-once-run-anywhere deployment: a component developed for database integration can execute without modification across server environments and 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 standardises this interaction layer, providing a uniform abstraction that decouples component logic from platform-specific implementations. WASI 0.2 formalises these interactions using WIT, an interface definition language that provides rigorous specifications for API contracts. Each system capability (including clocks, cryptographic random generation, filesystem operations, and HTTP services) is defined through structured WIT schemas that specify precise type signatures, behavioural semantics, and error conditions. These interface definitions enable automatic generation of language-specific bindings for high-level languages (e.g., Rust, Go, and AssemblyScript), allowing developers to invoke WASI APIs through idiomatic language constructs. The resulting compiled components achieve true platform independence, executing without modification across any WASI 0.2compliant host environment. By presenting a conceptual operating system interface, WASI decouples WebAssembly programs from underlying host specifics while enforcing a capability-based security model. Modules start with zero privileges and can access only the resources explicitly granted by the host through capability handles, ensuring strong isolation. All interactions occur through the WASI runtime rather than direct kernel syscalls, enabling secure, predictable, and portable execution of compiled components across any WASI 0.2–compliant environment. 2.3.1 WASI interface security WASI provides a conceptual operating system interface that decouples WebAssembly programs from host OS specifics by abstracting system functionality into a portable API layer implemented through WIT. Unlike traditional interfaces like POSIX, WASI enforces capability-based security where modules start with zero privileges and can only access resources explicitly granted by the host through capability handles. This "default deny" approach fundamentally changes syscall handling—instead of direct kernel access, all system interactions are mediated by the WASI runtime, creating strong isolation boundaries that prevent unauthorised resource access while maintaining portability across diverse platforms. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 25 - November 30, 2025 WASI is designed around the principle of least privilege, capability-based security, and sandboxing. These principles are enforced as follows: • Least Privilege: Applications only get access to the resources (files, sockets, clocks, etc.) they explicitly need. • Capability-based Access: All access to external resources is done via capabilities, i.e., opaque handles (“resources” in WIT terminology) that represent underlying resources. If a module does not have a handle to a file or directory, then it cannot access it. • Sandboxed Execution: WebAssembly modules run in a virtual machine with no direct access to memory, CPU instructions, or system calls. They can only interact with the outside world through WASI or other imported functions. In order to ensure the security of Wasm applications, WASI must satisfy three main properties. First, the behaviour of WASI calls must be identical across runtimes. This part is mainly related to the design of the specifications that must be as clear and unambiguous as possible. A difference in behaviour between several runtimes may lead to bugs and vulnerabilities. A side result of ours 34 is that the WASI random interface used to provide random data to initialise the canary value is behaving differently between runtimes, which may lead to predictable random data in some cases. This brings us to the second point, that the WASI APIs need to be safely designed, and especially the ones that are security-related. Interfaces such as the random one are susceptible to be used by cryptographic libraries, and thus, need to be provided with cryptographicallysecure random data, and being provided with predictable data is not acceptable. Other, less critical applications may require pseudo-random data without the need for strong guarantees. The specification of the WASI-random API was recently split in two, random and insecure, to take into account such situations. Finally, WASI must behave in the same way across multiple, varied environments. The enforcement of this property lies more in the hands of the runtimes' implementations, that must take into account the specificities of each platform they provide a WASI implementation for. A recent Go vulnerability 35 in a filesystem library, where opening a file behaved differently on Unix and Windows systems, shows that achieving identical behaviour on different platforms is still a challenge today. 2.3.1.1 Syscall isolation through virtualisation The key to WASI's isolation lies in syscall virtualisation. In traditional systems, applications make direct kernel calls like open("/etc/passwd", O_RDONLY) that bypass applicationlevel security controls. WASI eliminates this by intercepting and virtualising all system interactions. Consider file access: instead of calling open("/data/config.txt") like in a traditional OS, the host preopens a directory and assigns it a capability handle. The WebAssembly module then uses WASI syscalls such as: __wasi_fd_prestat_get(fd, &prestat); __wasi_path_open(fd, 0, "config.txt", FLAGS, RIGHTS, 0, &file_fd); Here, fd represents a capability granted by the host (e.g., access to /data), and "config.txt" is accessed relative to that capability. The module cannot access arbitrary filesystem paths, but it only sees resources the host explicitly provides, enforcing default-deny and least-privilege by design. 34 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. 35 https://nvd.nist.gov/vuln/detail/CVE-2025-0913 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 32 - November 30, 2025 2.3.5 Hardware accelerators As WebAssembly moves beyond the browser into cloud, edge, and embedded platforms, the need for secure integration with heterogeneous hardware platforms, e.g., GPUs, NPUs, and FPGAs, has become increasingly important. These environments require mechanisms that maintain WebAssembly’s strict isolation properties while enabling high-performance offloading of compute-intensive workloads. Recent surveys highlight issues such as driver isolation, memory-safety boundaries, capability-based resource modelling, and trust assumptions associated with accelerator backends. To address these needs, WASI and other runtime frameworks provide mechanisms that ensure isolation, integrity, and confidentiality. WASI is the primary standardisation effort for exposing system-level capabilities to Wasm modules in a secure and portable way. Two WASI sub-APIs currently provide standardised accelerator access: wasi-gfx and wasi-nn. The wasi-gfx interface (formerly wasi-webgpu) offers a general-purpose API for GPU acceleration within WebAssembly. Based on the WebGPU design, it exposes low-level interfaces for managing GPU memory, pipelines, and shader execution while enforcing strict host mediation. The guest programs interact only through opaque handles and validated resources, preventing direct access to native GPU drivers. Capability-based access controls ensure that resources cannot be misused or escaped. This design enables flexible execution of compute shaders, graphics pipelines, and custom kernels, providing high portability and performance at the cost of increased complexity and shader expertise. The wasi-nn API provides a high-level interface focused on machine-learning inference. It supports heterogeneous execution across GPUs, NPUs, TPUs, or CPU while enforcing strong sandboxing. Models and tensors are represented as opaque handles with no direct memory access, and the host selects the execution backend. Only inference operations are permitted, preventing arbitrary kernel compilation, and guest code handles only input and output buffers rather than device pointers. This constrained design ensures robust security, stability, and portability, making wasi-nn particularly suitable for edge deployments, although its functionality is limited to ML inference workloads. Beyond WASI standards, execution frameworks such as WasmEdge and Wasmtime provide mechanisms for secure accelerator offloading through host-mediated APIs. WasmEdge provides accelerator-oriented extensions tailored to heterogeneous computing environments. In more details, the WasmEdge-GPU enables secure and sandboxed access to GPUs, exposing WebGPU-like capabilities while ensuring that all interactions with the underlying graphics hardware are mediated through host-level interfaces. Likewise, WasmEdge-NN offers a dedicated extension for machine-learning inference. In both cases, WebAssembly modules do not have direct access to device drivers; instead, all GPU and NPU operations are strictly routed through controlled host APIs, thereby enforcing strong isolation, enhancing portability across hardware platforms, and enabling secure deployment scenarios. Similarly, Wasmtime supports secure accelerator integration and can be combined with the Component Model and custom host functions. Its integration with WIT enables fine-grained, capability-based access control, offering a structured mechanism for invoking accelerator functionality. This architecture offers high flexibility, making it particularly suitable for prototyping FPGA and GPU acceleration, and represents one of the most adaptable approaches for exploring emerging accelerator backends. Despite progress, several open challenges remain. WASI lacks a unified API spanning GPUs, NPUs, and FPGAs, and remote offloading to cloud accelerators raises questions about attestation, confidentiality, and communication security. Formal verification of shader validation, accelerator memory safety, and driver interactions is still in its early stages. Integrating confidential computing with accelerator access and addressing non-determinism in GPU-like devices also remain active research areas. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 33 - November 30, 2025 Overall, the combination of WASI standards and advanced Wasm runtimes provides a robust foundation for secure accelerator offloading. Through host mediation, capability-based access, and opaque resource models, WebAssembly can leverage heterogeneous compute resources while maintaining its core guarantees of isolation, safety, and portability. 2.3.6 Sensors WASI does not provide built-in support for sensors, a significant limitation for ELASTIC where we aim to deploy Wasm applications to far-edge/IoT devices with direct access to sensors. However, several hardware interfaces are being developed within various ELASTIC tasks, as reported in D2.1 38 (wasi-i2c and wasi-usb) and D4.1 39 (wasi-gpio). Providing direct access to hardware by Wasm components introduces a number of security challenges since the hardware may not provide any form of separation between sensitive devices (such as the system's nonvolatile memory) and non-sensitive devices (such as a temperature sensor), leaving the runtime to provide access control. These hardware interfaces come in two main forms: point-to-point interfaces such as GPIO and (often) SPI, where a CPU's physical hardware interface is used to interact with a single peripheral, and bus-type interfaces such as USB and I²C, where each hardware interface is able to interact with many peripherals at once. Point-to-point interfaces are easy to model by WASI's capability model: the runtime provides the application with a capability granting access to the hardware interface that it is permitted to use. The range of potential capabilities is determined by the device, and does not vary according to which peripherals are connected to the device. Bus-type interfaces such as I²C pose a greater challenge since the interface may be shared with many peripherals; this requires that the runtime be aware of the broader set of devices to which the interface is attached, and be able to distinguish between access to a permissible address and a non-permissible one at runtime. This leads to the need for more granular access control beyond merely the ability to grant access to a hardware interface, that can restrict how these capabilities can be used in terms of permissible addresses or peripherals. Nevertheless, this is still easy to model in WASI 0.2 by making use of Resources. Each resource can represent a specific device, and instead of giving a WebAssembly workload access to an entire interface, the runtime only gives it access to a specific resource. However, there are two challenges with this approach. The first challenge is in how the runtime determines which capabilities should be provided to the application. If an application requires a resource that represents a single USB device, how can the runtime know which USB device this is, and whether this access is allowed? Current specifications do not address these challenges, instead leaving it to the runtime to determine how capabilities are to be provided to the application. The second challenge is more inherent to the capability-based security model of WASI itself. While it is possible to restrict access on the level of WASI Interfaces and Resources, the standards do not provide a way to restrict access on a more granular level. As such, if a WASI interface for a USB device would be designed to allow a WebAssembly application granular access to an individual USB peripheral, then that is the only granularity level of access control that the standard supports. If this USB peripheral would support both reading and writing to the device, then the WASI standard can only model having access to either both or none. To make it possible to give a WebAssembly workload access to only read from the device, would require changing the API standard. The only way to enable more granular access control without 38 ELASTIC Project, Lightweight and Robust Orchestrating Mechanisms – Initial Version (Deliverable D2.1), Zenodo, 2025. doi: 10.5281/zenodo.15100798 39 ELASTIC Project, Lightweight and Robust Orchestrating Mechanisms – Initial Version (Deliverable D4.1), Zenodo, 2025. doi: 10.5281/zenodo.17590959 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 34 - November 30, 2025 changing the existing API would be to add an additional access control layer beyond the existing capability-based API. 2.3.7 Cryptographic Resources Cryptography in WASI currently focuses on WASI-Crypto, a low-level interface designed to provide portable cryptographic primitives to WebAssembly modules. While this approach offers modularity and host-agnostic design, it also places substantial responsibility on developers and exposes structural limitations in practice. WASI-Crypto is a low-level API in which the host provides fundamental cryptographic operations, such as digests, key derivation, signature verification, and symmetric or asymmetric operations. The modules rely on these primitives to implement higher-level functionality, such as secure channels, authenticated encryption schemes, and key management policies. This design preserves modularity and portability, aligning with WebAssembly’s design philosophy, but it also places responsibility on the developers to assemble security-critical protocols or integrate external libraries. Several significant issues arise from this low-level cryptographic functionalities focus. The custom or insufficiently maintained third-party cryptographic code introduces vulnerabilities, which increase the risk of misuse. By forcing developers to (re)build higher-level cryptographic logic, WASI-Crypto increases the risk of misuse and of introducing vulnerabilities through custom or insufficiently maintained third-party cryptographic code. Further limitations include the restricted algorithm surface, e.g., the widely used AES-CTR algorithm is not standardised, and the absence of a standard mechanism to enumerate a host’s supported cryptographic features, which complicates interoperability and runtime adaptation. Security controls and lifecycle properties are also limited: the key objects are associated only with a basic identifier and an optional expiration date, without enforceable usage restrictions or fine-grained access control. Also, implementations across runtimes remain experimental and inconsistent, further undermining portability. Finally, although WASI-TLS was originally designed to rely on WASI-Crypto, current implementations do not consistently build on it, highlighting the gap between low-level primitives and the needs of complex protocols such as TLS. Several approaches are available to address these limitations. Modules may use host-provided WASI-Crypto implementations, taking advantage of native optimisations where available, although support and algorithms remain inconsistent across runtimes. Alternatively, developers may compile a mature cryptographic library directly into the WebAssembly module, ensuring predictable behaviour, but increasing module size and maintenance responsibility. Delegation to host TLS or WASI-TLS interfaces allows modules to rely on hardened protocol implementations, although the support and the behaviour vary across platforms. Runtimespecific plugins can also provide WASI-Crypto capabilities, offering efficiency and hardware optimised integration at the cost of reduced portability. In more advanced setups, hosts can back keys using hardware security modules or trusted execution environments, exposing only cryptographic operations to modules, although these solutions rely on host-specific extensions rather than standardised WASI features. In terms of recommendations, sensitive modules should avoid implementing their own highlevel cryptographic logic internally and instead rely on host TLS or vetted crypto plugins, ensuring proper updates and maintenance for embedded libraries. Looking forward, the ecosystem would benefit from a revised WASI-Crypto built on the Component Model and incorporating capability discovery, enforceable key usage policies, richer key lifecycle management, and a minimum interoperable algorithm set. Such an evolution would reduce fragmentation, strengthen the security baseline, and facilitate hardware-backed cryptographic operations, better aligning WASI with the requirements of secure and high-assurance WebAssembly workloads. The main challenges in this area arise from the trade-off between minimalism and security: the primitive-only interface provides flexibility, but shifts complex and risky responsibilities onto ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 35 - November 30, 2025 developers. Limited algorithm support, inconsistent runtime implementations, and the absence of enforceable policies hinder interoperability and safe deployment. Without a standardised and security-aware cryptographic layer, developing robust and portable WebAssembly modules remains a significant challenge. 2.3.8 Custom access control The highly-structured nature of dataflows between Wasm components and between a Wasm component and the runtime provides a great opportunity for developers and platforms to insert their own access control mechanisms around untrusted components, and even around untrusted sub-components of a larger application. The composable nature of Wasm means that these access control mechanisms can be inserted into the application as a shim component without any special runtime support. Without the need for runtime support, developers can incorporate unusual application-specific checks or transformations that would never be implemented by a runtime, e.g., that a component can write to a certain file, but only if the data being written is valid according to some format specification, or that network traffic to the outside world will be mirrored to an intrusion detection system. Components implementing WASI interfaces can be linked with another component to wrap and mediate their access to the outside world, and WASI Virt 40 is a tool that allows a top-level component to be wrapped with pre-defined components that virtualise some or all of its WASI interfaces, causing it to run within an isolated environment. The limitation that only top-level interfaces can be wrapped is a significant limitation, as it restricts developers to an all-ornothing approach. The strong isolation between components means that a large library containing components from multiple sources need not always be treated as a monolithic block, and thus a well-informed application developer might choose to permit the library as a whole to access outside resources, but prohibit certain high-risk components from accessing them where it is known that this access will not be needed (e.g., where an image parsing library may access images from a URL, but the application developer knows that they will never pass a nonfile:// URL to the library). In this task, we have developed two tools, Wacky and Shimmer, that aid in the development and use of these isolation shims components. Wacky is an interposition tool that takes as input a set of shim components, as well as a change manifest, a file indicating a list of locations in the application where the shims should be inserted. Wacky builds on the wac tool, 41 automatically inserting shim components into the composition source code. This composition source is then used to link the application and shim components into a single binary for deployment. Shimmer is a scaffold generator that aids in the development of the shim components themselves. It generates the source for a complete buildable shim component according to a specified interface; the generated component directly implements the interface as extracted from the relevant WIT specification, implementing a passthrough shim that allows it to be immediately inserted into the application without affecting its function. 2.3.8.1 Performance evaluation To evaluate the overhead of shim interposition, we conduct a comparative benchmark using two configurations: a baseline two component composition and a three component composition with the shim inserted between components. This isolates the cost of adding a shim from computational costs by having the shim operate in pass through mode, excluding security mediation logic from measurement. 40 WASI Virt, https://github.com/bytecodealliance/wasi-virt 41 WebAssembly Compositions (WAC), https://github.com/bytecodealliance/wac ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 36 - November 30, 2025 Experimental setup The evaluation uses two Wasm component compositions, illustrated in Figure 1. The baseline case consists of a single untrusted component directly invoking another through a single interface boundary. The test setup then implements an additional access modifying shim as an intermediate component, with the shim forwarding all calls, creating two interface boundaries. Both configurations implement identical functional behaviour without internal modification to measure pure interposition overhead. Figure 1. Benchmark component configurations. The benchmark evaluation was conducted with the assistance of the criterion crate. Criterion is a robust Rust library that provides statistical analysis that is utilised to estimate the performance. 42 The test environment consisted of an AMD Ryzen 7 5800H, with 16GB of RAM, running Wasmtime 36 on a Windows 11 machine. The evaluation measures instantiation and invocation overhead separately, representing a distinct cost type with different performance characteristics and scaling behaviour. Instantiation is a fixed, one-time cost that occurs when a component is first initialised. Component initialisation is the process of creating a new WebAssembly component instance, including all associated runtime setup such as store initialisation, linking and memory allocations. Conversely, function call overhead is a recurring, per-call cost paid each time an already loaded component's exported function is invoked, representing the steady state operational expense. The instantiation benchmark measures the cold path cost by creating a fresh Store instance within each iteration. In contrast, the function call benchmark measures the warm-path cost as it uses the same instance of a pre-initialised component across all samples collected. As a result, this separation successfully isolates invocation latency from setup overhead. 42 Criterion.rs, https://github.com/bheisler/criterion.rs ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 37 - November 30, 2025 Instantiation Overhead The instantiation benchmark isolates and measures the time required to start a component from a pre-loaded module. By excluding module parsing and validation, which occur once during initial loading, each iteration measures exactly the cost of creating a fresh instance for both baseline and shim configuration. The probability density distribution for both configurations is shown in Figure 2. Tight clustering is observed around both configuration means, indicating stable and predictable instantiation behaviour. However, the shimmed tests exhibit slightly more variance and a wider spread than the baseline two-component measurements. The baseline mean is 68μs, while the shimmed component mean was higher, centred around 122μs. Mild outliers are evident in both cases, appearing as points scattered beyond the main distributions. These outliers are prominent and few, probably resulting from system-level interfaces such as memory allocator behaviour or cache effects. (a) ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 38 - November 30, 2025 (b) Figure 2. Instantiation overhead distributions. (a) Two-component baseline configuration, (b) Threecomponent shimmed configuration. A more detailed statistical summary of the two components baseline case's instantiation performance, is shown in Table 2. The two components' instantiation took an average of 68.39μs with a standard deviation of 1.92μs, demonstrating a high consistency of performance. On the other hand, the shimmed measurement consisting of the two previous components with an additional transit shim scored 122.09μs on average with a standard deviation of 4.08μs. Relative to the baseline, this introduces an absolute overhead of approximately 54μs and a 78.5% relative increase in instantiation time. Table 2: Instantiation performance. Configuration Instantiation time Standard Deviation Overhead (%) Baseline 68.39 1.92 Shimmed 122.09 4.08 53% Invocation overhead The function call benchmark experiments measure the time taken to invoke the functions at multiple frequencies ranging from 1 to 1000 calls. The functions deployed are simple passthrough functions, utilised to highlight the overhead introduction caused by adding a shim, which otherwise would be diluted by the introduction of computation heavy operations that would dominate the timing measurements. The components are pre-instantiated in these tests, isolating the per-call dispatch overhead from the once-off instantiation cost. The probability densities for 1000 function invocations are shown in Figure 3. The baseline call duration centres around 114 μs, while the shimmed component has a mean total call duration of approximately 120 μs, demonstrating minimal overhead. The absence of a long-tailed distribution or secondary peaks indicates that the shim addition does not introduce intermittent delays or timing variability. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 39 - November 30, 2025 (a) (b) Figure 3. Instantiation overhead distributions. (a) Two-component baseline configuration, (b) Threecomponent shimmed configuration. A summary of the results collected can be found in Table 3. It is clear to see that the shim introduces a steady and minimal overhead ranging from 6.2ns to 4.15μs along frequency calls spanning from 1 to 1000. Additionally, the relative overhead never exceeds 7%. This shows remarkable usability benefits and trade-off for inserting the shim for security as the cost for such a recurring natured operation, such as function calls, is not overbearing. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 40 - November 30, 2025 Table 3: Function invocation overhead Calls Baseline duration Shimmed duration Absolute overhead Relative overhead Per-call overhead 1 112.7ns 118.9ns 6.2ns 5.5% 6.2ns 10 1130ns 1200ns 70ns 5.9% 6.7ns 100 11260ns 11970ns 710ns 6.3% 7.1ns 1000 114200ns 118350ns 4150ns 3.6% 4.2ns The per-call overhead further highlights the minimal cost of adding shims with an approximate value of 6ns per call—the overhead hovers around the six marks with some variance. The slight variance of (±1.5ns) likely occurs due to noise and CPU cache effects rather than intrinsic behavioural differences. These results demonstrate an acceptable level of overhead, with a shim instantiation overhead of 53μs and per-call overhead of 6ns. Thus, the shim interposition imposes measurable but modest costs. The relatively high instantiation cost is an acceptable trade-off. It is a one-time cost that occurs only at the start-up, further balanced by the small function call overhead. The function call overhead performance is further enhanced with its scaling nature that remains constant across increasing calls without degradation. Lastly, both metrics exhibit predictable and deterministic overhead. 2.3.8.2 Limitations Wacky in its current form can successfully shim function calls present in Wasm interfaces; however, Wasm components can bypass these interfaces with the use of Resources, which can be passed between components, and allow their possessor to invoke methods on the resource, executed within the component that implements the resource. The interposition mechanism itself must be enhanced in order to intercept resource method calls; this is more complicated than intercepting function calls, since the shim component must attach to every interface that uses this resource type, and not merely the interfaces of untrusted components. This leads to highly complex shims that must be applied globally to the application's components when intercepting methods of common resource types like I/O streams. Alternatively, we might implement a wrapper resource implemented by the shim component; then, a second shim can be applied at the boundary between the trusted and untrusted components to convert between the original, unshimmed resource, and the corresponding wrapper resource. This reduces the overhead of resource shimming in comparison with the global application of a shim to trusted and untrusted components alike. In the particular case of I/O streams, we might plausibly extend the runtime with the ability to create pairs of connected stream resources, allowing a shim component to substitute one half of such a pair for any native host streams that passes through its interface, essentially capturing untrusted components' I/O with the existing resource implementation. However, this approach does not apply to other interfaces, for which we must apply global shimming as described above. 2.4 Security of Wasm applications during orchestration and migration The Wasm component model allows for the creation of applications out of composable subblocks that are fully isolated from one-another by the Wasm sandbox. This strong intraapplication isolation requires a different approach to security, shifting from a software security mindset to a network security mindset, as more and more of the application's functionality is no longer encoded into the well-sandboxed Wasm code, but rather into the linkages provided by the runtime between the Wasm components themselves, and between Wasm components and functionality directly provided by the runtime. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 41 - November 30, 2025 We consider two main security challenges in this document: First, how to describe a complex Wasm-based application in a way that allows access control and attestation mechanisms to differentiate between its different components, and second, how to maintain the continuity of an application that may be subject to forced migration between hardware platforms during operation. In WP3, we consider the related problem of maintaining a consistent application identity when its components are distributed across several physical platforms; we do not reproduce this work here, which is described in D3.1 43 . 2.4.1 Wasm application identity We have examined two main models for the deployment of Wasm applications: ● “Composed” applications that use the native features of the component model to describe themselves in terms of their underlying subcomponents, and that can be directly assembled by a component-model-aware Wasm runtime such as Wasmtime 44 into a single in-process application, in order to allow low-latency in-process communication. ● “Orchestrated” applications that are described in a high-level form that will be used by a platform such as WasmCloud 45 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. 46 Both models can be used to describe the same application, 47 which will have the same behaviour despite very different representations. This observation, same behaviour, different representations, drives our central problem. Even within the same model, multiple representations of the same application may exist. Composed applications may include their components in a different order, e.g., if it is optimised (or not) by deduplication of component definitions; orchestrated deployments can vary in layout while preserving semantics. 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, policy, and remote attestation. By enabling attestation mechanisms to capture the functionality of a Wasm application independently of the deployment configuration that enables such a configuration, we can ensure its correct operation without consideration of the correctness of the orchestrator, thereby significantly reducing its trusted computing base. 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 we use it to construct a canonical representation of the application. We define this canonical representation as application identity. Intuitively, the identity is a digest of the graph that is stable under syntactic reordering, benign deduplication, and other representation-level variations that do not change semantics. By 43 ELASTIC Project, Lightweight Confidential Computing Platform - Initial version (Deliverable D3.1), Zenodo, 2025. doi: 10.5281/zenodo.17590951 44 https://github.com/bytecodealliance/wasmtime 45 https://wasmcloud.com 46 https://github.com/bytecodealliance/wrpc 47 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 48 - November 30, 2025 (b) Dispute resolution by the TTP in the case of a failed migration. (c) Dispute resolution by the TTP in the case of a successful migration that could not be confirmed by the source and destination. Figure 6. Workflow of fair component migration in ideal case. We propose a fair migration that leverages this asynchronous optimistic fair exchange as a subprotocol to confirm migration of resources and transfer of responsibility between two hosts, yielding a non-repudiable confirmation at the end of the protocol that the migration succeeded or failed. In the ideal case where no dispute takes place, the protocol consists of two hosts like in the ineffective gradual exchange: Source (S) and Destination (D). ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 49 - November 30, 2025 Each host contains a daemon that is responsible for coordinating migration, separate from the runtime, orchestrator, and other application functionality. This separation allows this migration protocol to be applied to the widest variety of possible applications. We refer to this daemon as the Agent and its client as the Runtime: • Agent: Takes care of the logical part with fair exchange migration protocol. The daemon dispenses cryptographic resources such as signature and asymmetric keys. • Runtime: Focuses on the physical migration of the resource. This resource may be a snapshot of memory, file contents, a DNS record, or an abstract statement of responsibility for some task. Figure 7 describes the workflow of our proposed protocol in an ideal case with no dispute to resolve. First, any bulk data to be migrated (e.g., the binary of a component) will be transferred from source runtime RuntimeS to destination runtime RuntimeD (Step 1). This, if it is successful, will be followed by a confirmation sent by RuntimeS to the source agent AgentS (Step 2). AgentS and the destination agent AgentD then execute the fair exchange protocol34 (Step 3), in the process confirming with RuntimeD that the initial transfer completed successfully (Steps 4 and 5). After obtaining this mutual certificate, those two agents terminate the fair exchange protocol (Step 6) and pass the certificate to their respective runtimes (Step 7). Figure 7. Workflow of fair component migration in ideal case. In exceptional cases, the presence of a TTP is required. This can be instantiated using a TEE to allow both source and destination to establish trust in the TTP to follow the designed protocol. The TTP then communicates directly with AgentS and AgentD to achieve the final goal of providing them with a certificate certifying the success or failure of the migration. However, a TEE can only guarantee the confidentiality and integrity of the TTP's state and functionality, and not its availability. This suggests the need for a distributed TTP based on Byzantine Fault Tolerance or some other approach that will not introduce a single point of failure for the ELASTIC framework. How best to instantiate this TTP will be the subject of further work in T3.2. 2.5 Proposals and recommendations Based on our analysis, Wasm is suitable as an application isolation technology for the ELASTIC framework. However, we have identified several areas for improvement, as well as opportunities to extend Wasm's security functionalities for the future. The Wasm sandbox provides a high degree of protection against malicious applications, but its design forces applications to give up some of the protections that are available to them when running as native code (e.g., randomisation mechanisms such as Address Space Layout Randomisation). Furthermore, important differences between the design of the Wasm architecture and that of physical CPUs make naive ports to Wasm impossible. We have ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 50 - November 30, 2025 analysed the security of the current implementation of Stack Smashing Protection for Wasm in the LLVM compiler suite (based on the one provided to natives binaries), identified several weaknesses and implemented a robust Stack Smashing Protection mechanism leveraging Wasm features in order to ensure the effectiveness of the protection for Wasm. We propose that this be used where possible, as well as recommending, beyond the scope of this project, further security analysis for Wasm and development of new mechanisms replicating those available to unsandboxed code. We recommend that this be incorporated into the mainline LLVM compiler to allow applications outside the ELASTIC ecosystem to benefit from these developments. In addition, side channels remain a risk to the confidentiality of Wasm code, even when run inside a TEE. We recommend that CSPs execute workloads with high confidentiality requirements on physically-separated machines in order to avoid shared tenancy with untrusted code. The Wasm sandbox intercepts all access to host functionality, and applies a capability-based access control scheme to a wide variety of external resources. The "opt-in" nature of these capabilities, where components have no access to anything until the runtime has provided a capability, should be used by the ELASTIC HAL to grant access to these resources at a very granular level, e.g. by granting applications access only to their own isolated filesystem hierarchy, or restricting network access to public IP address. We also propose the use of Wasmbased access control shims to allow the application of even stricter policies that cannot be expressed using existing runtime implementations, in order to allow these policies to be applied to cross-platform code that may be executed on runtimes not subject to modification. Since Wasm applications are decoupled from the underlying host implementation of external resources, Wasm provides a great opportunity for orchestrators, which can more easily migrate resources between physical machines, potentially even without the knowledge of the workloads that depend on them. However, this introduces new distributed systems challenges which we propose to solve using our newly-developed migration component based on fair exchange. Wasm's highly-structured binaries with intra-application isolation also provide new opportunities for TEE-based systems, which can independently attest individual parts of an application, significantly reducing the TCB of systems that require attestation of only small pieces of functionality. We propose a new method to describe composite Wasm applications, independently of their composition and placement by developer tooling orchestrators, and recommend further development, ideally in such a way as to allow incorporation into mainstream Wasm runtimes. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 51 - November 30, 2025 3 eBPF This section presents the results of the ELASTIC project to investigate and improve the security of eBPF (Section 3.1) and to achieve low-latency communication and security using eBPF (Section 3.2). Then, it presents the related tools that have been developed within ELASTIC T1.3 to achieve KPI 1.2 54 (Section 3.3) and EO-KPI-09 55 (Section 3.4). 3.1 eBPF/XDP security investigation A thorough investigation of the security of eBPF and XDP has been conducted within ELASTIC through a systematic literature review of the topic (Section 3.1.1), an analysis of eBPF-related known vulnerabilities published in the Common Vulnerabilities and Exposures (CVE) database (Section 3.1.2), and an experimental study of the exposure of eBPF C-code to security vulnerabilities not detectable by the verifier (Section 3.1.3). Based on these studies, in Section 3.1.4, we identify and classify the main threats, vulnerabilities, attack surfaces, and exploitation techniques of eBPF programs, and then present the available mitigation techniques (Section 3.1.5) and provide final considerations and recommendations for using eBPF as securely as possible (Section 3.1.6). 3.1.1 Systematic literature review 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. Each paper was then manually screened on the 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 relevant search results. The scientific papers identified 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, how it can be exploited for malicious purposes, such as concealing the attackers’ activities after the exploitation of system vulnerabilities (security with eBPF). 2. General discussions on the adoption and evolution of eBPF, often highlighting its value in system and network operations, and occasionally touching on associated security risks. 3. Research that explicitly analyses the security of the eBPF system itself, focusing on its internal vulnerabilities and potential weaknesses (security of eBPF). 54 ELASTIC Project R&I 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. 55 ELASTIC Project Impact KPI EO-KPI-09): Eliminated 90% of all known security 6G networks vulnerabilities using modern ELASTIC tools, i.e., eBPF and IDS. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 52 - November 30, 2025 While the first category is 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 focuses on the intrinsic security of the eBPF technology rather than its use for external security purposes. The second is also of limited relevance. The third category, which investigates the security of eBPF, is of primary interest, as it addresses the vulnerabilities of the eBPF system and its components, such as the verifier, JIT compiler, runtime, helper functions, maps, and attachment mechanisms. Papers in this category have been considered relevant. A structured spreadsheet was used to track the inclusion/exclusion of each paper, along with a brief justification for each 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. The literature relevant to this review reveals several recurring research directions, which can be grouped into the following main classes. 1. Studies providing broad assessments of eBPF’s security posture, mapping out its potential attack surfaces. 2. Description of attack techniques that exploit specific vulnerabilities in the eBPF system, possibly in combination with other known non-eBPF vulnerabilities, to compromise the kernel security (DoS, sensitive data leakage, privilege escalation, etc.). These papers also present possible countermeasures. 3. Systematic approaches for identifying vulnerabilities, such as advanced fuzzing techniques to generate eBPF code that may trigger vulnerabilities in 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 aimed at enforcing correctness in critical parts of the pipeline. For the purpose of this study, the papers in classes 1., 2., and 3. are used to identify the main threats, vulnerabilities, attack surfaces, and exploitation techniques relevant to the eBPF system, while the papers in classes 2. and 4. are used to identify the main mitigation techniques for such threats. The various methods reported in the literature to create eBPF malware, i.e., code that can harm the system or perform unauthorised operations, are described in the reminder of this section. Most 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 become public. Exploitation of eBPF verifier bugs: 56 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 by causing the verifier to incorrectly accept as valid a program that is actually invalid, making it unsafe or insecure to execute. By exploiting such a bug, an attacker can load a malicious eBPF program that should not be loaded, potentially resulting in serious security consequences. eBPF verifier bugs of this kind are continuously discovered, and fixed, and documented in the literature. Recently, the search for exploitable verifier bugs has become more systematic through the use of dedicated fuzzers. This technique has led to the discovery and resolution of many additional eBPF verifier bugs. However, as the verifier is constantly evolving, new bugs may be introduced, and undisclosed bugs may still exist. For completeness, there is another type of security vulnerability due to eBPF verifier bugs: the verifier’s code itself may contain a 56 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 53 - November 30, 2025 security vulnerability that can be triggered by attempting to load malicious programs specifically crafted to exploit it. Exploitation of eBPF JIT compiler bugs: 57 Some bugs in the eBPF JIT compiler have been exploited by crafting malicious eBPF programs that pass verification but trigger JIT vulnerabilities, causing kernel crash or even hijacking of the kernel control flow. Exploitation of eBPF helper functions: 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. The verifier assumes these functions are safe to execute and performs only a few checks on their arguments. However, as documented by Jia et al., 58 eBPF helper functions may have their own vulnerabilities that can be exploited by calling them in specific ways from malicious code. For example, the abovereferenced paper showed that nested calls to the bpf_loop helper function could be used to create malicious eBPF programs that effectively do not terminate, and that certain helper functions can crash the system when called with unexpected arguments not prohibited by the verifier. Several vulnerabilities like these ones are continuously discovered and patched in the Linux kernel. As the number and complexity of eBPF helper functions constantly grows, so does the number of introduced vulnerabilities. BPF program nesting: 59 : A specific issue related to the use of helper functions is that, although each verified eBPF program has its stack capped at 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, another eBPF program may be attached to function calls that occur within a helper function. If this happens, the other eBPF program is executed nested within the execution of the first program that called the helper function. Because the verifier does not account for these situations, such nested executions may cause the kernel stack to overflow. While the cap applies to each eBPF program individually, when one program is executed within another, the combined stack usage may exceed the limit. Cross Container Attacks: 60 Various attacks enabling container escape have been demonstrated when eBPF is used inside containers, as container isolation is limited with respect to eBPF. Most notably, He et al. pointed out that eBPF programs can trace processes across the entire system, not just those within the container, which can be exploited to escape the containers in which they run. This can be achieved by using well-known offensive BPF helper calls that inherently compromise system security, especially in container environments, and by employing strategies (as documented in the paper) to bypass traditional container isolation mechanisms. Through these attacks, eBPF code running in the container can target 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 other containers. The risk is significant because many real containers enable eBPF, even allowing the execution of offensive helper calls. 57 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 58 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. 59 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. 60 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 54 - November 30, 2025 EPF (Evil Packet Filter) 61 is an attack methodology that exploits the Linux kernel’s BPF infrastructure to inject malicious payloads, which can be used to create exploits in combination with kernel memory corruption errors such as buffer overflows. The Linux kernel employs several techniques to make exploiting security vulnerabilities like buffer overflows impossible or very difficult; these techniques prevent user code or data from being executed or accessed freely by the kernel). The attacks described 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. These attacks 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 kernel vulnerabilities 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 aimed to create ROP chains using a third writable memory region. Speculative Execution Attacks: 62 , 63 These attacks, also known as transient execution attacks, exploit the speculative execution mechanisms in modern processors. These predict which instructions will be executed next and temporarily execute them to improve program performance, reverting the execution state if the prediction is incorrect. However, this mechanism can be exploited to leak secrets through covert channels (e.g., the cache). The most common speculative execution attacks are known as Spectre. As eBPF programs can be jitcompiled 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 discovered since the first one was identified 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, existing mitigations are not definitive solutions. 3.1.2 Analysis of eBPF-related CVEs This section presents a comprehensive study of the 249 eBPF-related CVE entries published between 2014 and April 2025. The primary objective is to gain a deeper understanding of where, why, and how these vulnerabilities occur. To conduct this empirical analysis, the study combined automated data collection with manual refinement and structured classification. Starting from the entire CVE archive in the National Vulnerability Database (NVD) (as of April 29, 2025), the dataset was filtered using keyword searches and manual inspection to identify the Linux kernel vulnerabilities specifically related to eBPF. Each CVE was enriched with metadata from the Linux kernel Git history (e.g., patch commits and affected files), and categorised using Common Weaknesses Enumeration (CWE) tags, kernel version mappings, and Common Vulnerability Scoring System (CVSS) severity available from the dataset. Dedicated analyses were performed to answer specific research questions concerning temporal trends, patch latency, vulnerable modules, root causes, exploit characteristics, and their severity or impact. The analysis yielded several notable findings, summarised below. 61 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 62 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 63 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 55 - November 30, 2025 Temporal Distribution (RQ1): As shown in Figure 8, there is a clear upward trend in the number of eBPF-related CVEs over time. A significant increase occurred between 2021 and 2022, with more than a twofold rise from late 2023 onward. The first third of 2024 saw a peak, with over 60 new vulnerabilities reported. A smoothed curve obtained by interpolation reveals a nonlinear, accelerating trajectory, suggesting that eBPF has become an increasingly critical and exposed component in the Linux kernel. Figure 8. Temporal distribution of eBPF CVE entries. Evolution Across Kernel Versions (RQ2): The number of eBPF-related CVEs affecting the initial release of each Linux kernel minor version (Figure 9) shows a steady increase starting with version 4.14, peaking at over 100 CVEs in version 5.10, which is a Long Term Support (LTS) release. LTS versions often appear as local maxima, likely reflecting more intensive development and backporting activities within those releases. Figure 9. Number of eBPF CVEs affecting the initial release of each Linux kernel minor version. Patch Latency (RQ3): For 70% of the CVEs, the average time-to-fix is 1,037.6 days, with a median of 737 days. The maximum delay observed was 7,744 days. There is no clear temporal pattern — some vulnerabilities are fixed within weeks, while others persist for years. Additionally, there is no strong correlation between patch latency and severity (the correlation value is 0.06). Overall, eBPF vulnerabilities tend to remain in the kernel for two to three years before a patch is merged, regardless of severity. This long persistence, associated with the high ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 56 - November 30, 2025 occurrence rate, is concerning and indicates that the eBPF system could be a significant catchment area for zero-day vulnerabilities. Most Affected Modules (RQ4): As shown in Figure 10, the verifier is by far the most impacted module. It is followed by the networking subsystem, the core, and the helpers/maps modules. File-level analysis confirms this trend: verifier.c is the most frequently modified file in CVErelated commits, appearing in nearly 70 commit instances. Both moduleand file-level analyses consistently highlight the verifier as the most vulnerable and maintenance-intensive component of the eBPF subsystem. Figure 10. Number of eBPF CVEs by category (i.e., module). Severity and Exploitation Characteristics (RQ5): The results of the analysis of the severity and exploitation characteristics are shown in Figure 11. The average CVSS base score is approximately 6.3, placing most vulnerabilities in the Medium–High severity range. The median score is 5.5. The highest third-party score is 9.1 (Critical), while the highest NVD score is 8.8. Vector analysis reveals that attack vectors are almost always classified as Local, with Low attack complexity and Low privilege requirements. User interaction is almost always None, and the Scope rarely changes. Availability is the most affected security property, with most CVEs scored High in this dimension. Confidentiality impact is High for about half of the dataset, while Integrity is less frequently affected, but scores High in about one third of cases. Figure 11. Analysis of severity and exploitation characteristics of eBPF CVEs. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 57 - November 30, 2025 3.1.3 Study of the exposure of eBPF C-code to security vulnerabilities Software vulnerabilities can be introduced when developing eBPF programs as with any other program, but not all of them violate the memory safety, and access control policies or the restrictions enforced by the eBPF verifier. For example, integer overflows or implicit type conversions in C programs, which are known to be among the possible causes of unintended behaviour in C programs and security vulnerabilities, are not detected or prevented by the eBPF verifier, as confirmed by our experiments. This implies that code security vulnerabilities may affect any eBPF program loaded into the kernel. The risk associated with this issue is usually not highlighted in scientific publications or guidelines for eBPF security, such as the “eBPF Security Threat Model”, 64 a whitepaper commissioned by the eBPF Foundation to provide eBPF security information and guidance. Within ELASTIC T1.3, a study was conducted to identify which common causes of security vulnerabilities in C programs are detected and blocked by the C compiler or eBPF verifier, and which are not. The reference for determining the C code weaknesses to be considered in the study was ISO/IEC TS 17961:2013 (C secure coding rules), which enumerates the secure coding rules that should be followed to avoid the most common C code security vulnerabilities. The document also recommends that the violations of such rules be diagnosed by C code analysis tools specialised in identifying code security vulnerabilities. The methodology of our study involved injecting violations of the ISO/IEC TS 17961:2013 secure coding rules into real eBPF C code to test how such violations are handled by the typical C-based eBPF code pipeline (Clang compiler, eBPF verifier, JIT compiler) in a Linux system. Of the 46 coding rules in ISO/IEC TS 17961:2013, 21 do not apply to eBPF code due to eBPF restrictions (e.g., operations on files are not permitted in eBPF code). The remaining 25 rules were covered with a total of 60 test cases (one per rule, plus additional stress tests). Each test case is derived from a real eBPF program, taken from the Linux kernel selftests, and modified by injecting a violation of one of the ISO/IEC TS 17961:2013 coding rules. Of the 60 test cases, 4 were rejected by the Clang compiler, and 15 were rejected by the eBPF verifier, while 43 passed eBPF verification and could be loaded. Of these 43 test cases, 18 were found to be non-vulnerable due to code adjustments made by the verifier or runtime barriers (e.g., division by zero is adjusted to prevent a crash), while the remaining 25 were identified as potentially exploitable vulnerabilities. This study confirms the existence of C code vulnerabilities that can be introduced into eBPF C code without being detected by the usual eBPF development pipeline. Since this possibility is not emphasised in the eBPF security literature, and the scrutiny of the eBPF verifier may give the developers a false sense of security, it is crucial to address this issue properly. 3.1.4 Threats, vulnerabilities, attack surfaces, and exploitation techniques From the previously presented analyses, the following 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. These threats occur 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 tricked into loading eBPF code that contains malware. An attacker can achieve this in various ways, such as by publishing the malicious code in public code repositories. If a privileged user is tricked into using the malware, 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 that includes eBPF code containing malware. Even if the eBPF code runs inside the container, it has 64 J. Kelly, J. Callaghan & A. Martin, “eBPF Security Threat Model”, available: https://control-plane.io/publications/ebpfthreat-model ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 64 - November 30, 2025 implements mesh features. The requirement of maintaining total end application transparency has led to the use of Network Address Translation (NAT) techniques to achieve effective traffic interception in traditional service mesh architectures. However, modern designs are being proposed that replace the NAT layer with a customised eBPF-based data path, motivated by efficiency and performance improvements. In this subsection, this claim is verified by testing and performing architecture studies on several competing service mesh solutions to evaluate the expected performance gains of eBPF dataplanes. Service mesh solutions considered. For the remainder of this evaluation section, we examine several service mesh platforms and configuration combinations: ● Istio 78 sidecar-based with traditional NAT dataplane. The Istio service mesh is one of the most widely used service mesh solutions in production clusters, thanks to its extensive feature set and established community. In its default configuration, Istio is deployed as a sidecar-based mesh where an instance of the proxy process (Envoy 79 in this case) is placed in each computing container alongside the target application. ● Istio sidecar-based with custom “Merbridge” 80 eBPF dataplane. As an optional modification of a typical Istio installation, the Merbridge custom data path can be used, to replace the traditional NAT network backend with an eBPF alternative. Testing the same service mesh under both NAT and eBPF modes through Merbridge gives us the ideal platform to minimise “feature noise” and conduct this evaluation. ● Istio sidecarless (“ambient mode” 81 ) with traditional NAT dataplane. In recent versions, Istio offers an alternative operating mode called “ambient mode”, where the per-container Envoy process is substituted by their custom in-house “ztunnel” proxy, deployed monotonically on a one-per-node basis. As of the writing of this report, Istio ambient-mode does not support an eBPF dataplane, and runs exclusively under NATting. ● Linkerd 82 with traditional NAT dataplane. Linkerd is an alternative service mesh platform that shares many architectural characteristics as Istio. Specifically, it follows the same sidecar-based design as traditional Istio, though relying on a custom, purposebuilt proxy rather than standard Envoy. ● Linkerd with custom “Merbridge” eBPF dataplane. Similarly to the sidecar-based Istio, Linkerd also supports the Merbridge custom eBPF data path. ● Cilium Service Mesh. 83 The open-source Cilium project is a CNI implementation frequently used to provide connectivity between containers in Kubernetes clusters. Crucially, Cilium makes extensive use of eBPF technology for general container networking purposes, aiming to achieve high performance and scalability by reimplementing much of the LKNS’s functionality as customised eBPF code. In addition to container networking, Cilium offers a service mesh solution that builds on top of its highly performant eBPF dataplane. Unsurprisingly, Cilium’s service mesh functionality also runs eBPF under the hood to implement typical service mesh features. Unlike alternatives based on the Merbridge plugin, Isovalent’s implementation represents the theoretical best case scenario for an eBPF service mesh, as it is codesigned with the underlying network stack. However, this comes at the cost of crossCNI compatibility, as the Cilium service mesh only supports the Cilium CNI. This wide and heterogeneous set of alternatives allows us to extract fundamental principles and draw decisive conclusions about the effectiveness of eBPF dataplanes for service mesh implementations. 78 “Istio Service Mesh homepage.” https://istio.io/ (accessed Jun. 13, 2025). 79 “Envoy: open source edge and service proxy, designed for cloud-native applications.” https://www.envoyproxy.io/ (accessed Jun. 13, 2025). 80 “Merbridge: use eBPF to accelerate your mesh.” https://merbridge.io/ (accessed Jun. 13, 2025). 81 “Istio Ambient Mode.” https://istio.io/latest/docs/ambient/ (accessed Jun. 13, 2025). 82 “Linkerd Service Mesh homepage.” https://linkerd.io/ (accessed Jun. 13, 2025). 83 “Cilium Service Mesh.” https://cilium.io/use-cases/service-mesh/ (accessed Jun. 13, 2025). ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 65 - November 30, 2025 Architecture of traditional NAT-based dataplanes. As mentioned above, several of the considered service mesh solutions employ NATting as the default network data plane backend for the mesh infrastructure. Specifically, the Linux NetFilter firewall is configured directly in the target application’s network namespace via iptables (or an equivalent tool) to translate the destination IP address and port of outbound and inbound packets, steering traffic towards sockets owned by the proxy process. Redirection performed at the NetFilter level, either from the PREROUTING or OUTPUT chains for inbound and outbound traffic respectively, is subject to hairpinning through the stack’s loopback virtual interface. This requires both full transmission and reception stages for each packet, resulting in an additional SoftIRQ context switch in the data path, thus causing overhead. Variations of this mechanism are utilised by default by both the Linkerd and Istio service meshes, including Istio ambient mode deployments, where a per-node ztunnel proxy is shared by multiple application network namespaces. In this scenario, the Istio control plane infrastructure responds to the addition of new services to the mesh by opening all required ztunnel sockets within the same network namespace of the new service. This exploits a quirk in the Linux network namespace infrastructure that allows a process’s network namespace to differ from that of its owned sockets. Overall, the same traffic interception architecture can be adapted with minimal changes, as the designated ztunnel sockets for each target application will be directly reachable from within the application’s namespace. Architecture of eBPF dataplanes. Traditional service mesh dataplanes based on NetFilter NATting suffer from increased computational load due to (i) the application of iptables rules, which notoriously exhibits low scalability as a result of the linear matching algorithm, and (ii) the presence of an additional SoftIRQ context switch caused by the loopback round-trip. Custom eBPF dataplanes aim to mitigate both issues. Merbridge uses several eBPF programs injected into the kernel’s network stack to intercept traffic. Outbound connection attempts from monitored applications are instrumented using a BPF_PROG_TYPE_CGROUP_SOCK_ADDR program attached to one of the BPF_CGROUP_INET{4,6}_CONNECT hook points. Similar to DNAT, this allows the infrastructure to replace the destination address and port with the expected proxy endpoint. As a result, the system establishes the connection directly with the proxy process. However, rewriting the packet’s addresses would route traffic through the loopback interface, which should be avoided. Therefore, Merbridge performs destination address NATting only on the TCP SYN packets used to first open the connection, invoking the proxy socket and registering this association internally. Subsequent traffic packets are redirected between the application and proxy sockets directly via eBPF SK_MSG packet steering. Direct SK_MSG redirection avoids any involvement of the virtual loopback interface, thus enabling process-to-process traffic flow. Inbound traffic is handled similarly, accounting for different proxy endpoints. The Cilium service mesh is fully integrated into the eBPF routing infrastructure provided by the Cilium CNI plugin. This means that service mesh functions are included in the overall eBPF host routing stack described in Section 5.2.1 of Deliverable D1.1. Furthermore, the Cilium service mesh attempts to minimise proxy invocations by offloading many of the typical service mesh functionalities directly to eBPF, including L3 and L4 policy enforcement and traffic encryption. In fact, the Cilium service mesh uses in-kernel WireGuard or IPsec VPN tunnels to secure inter-service communication, whereas proxy-centric meshes usually rely on userspace TLS implementations to secure inter-cluster communications. Methodology, results, and discussion. For our performance assessment task, we focused on the throughput and latency metrics achieved between a pair of pods in a multi-node Kubernetes cluster under the considered service mesh combinations. The pods were intentionally scheduled on separate cluster nodes in order to minimise the impact of host networking optimisations for intra-node workloads under some of the tested CNI plugins. The nodes were connected via a ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 66 - November 30, 2025 100Gbps physical Ethernet LAN to avoid bottlenecks. The Flannel CNI plugin 84 was used for all service mesh solutions except Cilium, due to its simplicity and straightforward design. Throughput was measured as both raw TCP goodput supported by the mesh infrastructure, and peak HTTP Requests Per Second (RPS) at varying response sizes; we used iperf3 85 and the wrk 86 benchmark with an nginx 87 backend for these tests, respectively. wrk was also used to extract latency information representative of a real-world workload. Finally, service meshes were configured with default settings and minor performance tweaks (such as enabling most of the additional eBPF-based optimisations offered by the Cilium CNI plugin). This provided a consistent baseline to effectively isolate the impact of the traffic steering technology used by each service mesh solution, whether it was based on NetFilter DNAT or eBPF. It should be noted, however, that the default configuration includes full traffic encryption, which appears to be mandatory on the Cilium service mesh. Figure 13. Measured throughput (top) and latency (bottom) under multiple service mesh combinations. As can be seen in Figure 13, excluding the Flannel and Cilium “baselines” (that portray the base performance of the respective CNI plugin without a service mesh enabled), no single solution clearly excels in both throughput and latency. In fact, throughput appears to favour Envoy-powered Istio, while latency (and consequently low-size HTTP RPS) benefits Istio ambient mode and Cilium. Notably, no significant difference can be observed between the performance of the NetFilter and Merbridge backends for Istio sidecar (Merbridge under the 84 “flannel is a network fabric for containers, designed for Kubernetes,” Github. https://github.com/flannel-io/flannel (accessed Jun. 13, 2025). 85 “iPerf - The TCP, UDP and SCTP network bandwidth measurement tool.” https://iperf.fr/ (accessed Jun. 13, 2025). 86 “Wrk: Modern HTTP benchmarking tool,” Github. https://github.com/wg/wrk (accessed Jun. 13, 2025). 87 “nginx HTTP Web Server homepage.” https://nginx.org/ (accessed Jun. 13, 2025). ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 67 - November 30, 2025 Linkerd service mesh seems to be nonfunctional at this time, as some of our test workloads could not communicate successfully with it). Furthermore, Cilium performs below our prior expectations. Given these early experimental results, we propose an explanation for the unexpected outcome. Our original objective was to isolate the cost of the traffic interception mechanism, since that is where eBPF is used in service mesh implementations. However, even with minimal configuration, all meshes perform traffic encryption, which we suspect overshadows all other components of the network stack. This is also suggested by comparing Istio sidecar mode (with NetFilter backend) and Istio ambient mode: these differ only by the specific proxy used (Envoy and ztunnel, respectively), and yet showcase remarkably different performance. As a reminder, Istio and Linkerd perform traffic encryption in userspace with TLS. Additionally, some of the typical reasons for replacing iptables NATting with custom eBPF counterparts do not necessarily apply here, as the known inefficiency of the iptables linear rule matching only becomes problematic when the number of installed filtering rules is large. For the service mesh use case, iptables installs its redirection rules in the target application’s network namespace, where no other NetFilter rules are expected to be found, regardless of cluster size or other external factors. Based on these findings, system administrators should avoid selecting a service mesh solely on the promise of eBPF-accelerated dataplanes, as the measured performance improvements were negligible once encryption and proxy overheads dominated end-to-end costs. In practice, administrators should prioritise the maturity and operational characteristics of each mesh; Istio sidecar mode remains a strong default for high throughput, while Istio ambient mode and Cilium offer favourable latency profiles but also introduce architectural constraints such as mandatory encryption and, in Cilium’s case, tight coupling to its CNI. Organisations seeking simplicity and predictable behaviour may prefer traditional NAT-based meshes, since iptables overheads appear insignificant at the scale of per-namespace redirection rules. eBPF dataplanes, including Merbridge, should be considered experimental optimisations rather than guaranteed performance upgrades, and adopted only when their operational complexity and CNI compatibility limitations are acceptable. Ultimately, mesh choice should be driven by feature requirements, ecosystem fit, supportability, and encryption strategy rather than assumptions of dataplane speedups. 3.2.3 eBPF deployment performance evaluation With the evident power and speed advantages that eBPF brings in improving the monitoring, observability, and optimisation/fine-tuning of the network’s performance, as noted in the introduction to this section, the performance overheads of the possible eBPF implementation options become increasingly significant. Methods for evaluating these overheads therefore are a relevant factor, particularly in 6G (and 5G) application scenarios with ultra-low latency and high reliability requirements, such as the ELASTIC real-time mobile robot control case in the Smart Manufacturing Demonstrator 1 in WP5 88 . These deployment performance overheads, previously considered earlier, are approaching the temporal order of magnitude as the execution performance gains and latency reduction provided by eBPF implementation for real-time network events monitoring (compared to traditional methods). Understanding the impact of eBPF execution on the overall system’s performance under different configurations is crucial for harnessing its full potential. 89 Consequently, there is a growing need of reference methods for comparative evaluation and benchmarking, including in containerised (Kubernetes) implementations common in commerce and industry (with potential for service/throughput cost savings). A relevant example for Calico and Cilium 88 More information can be found in ELASTIC Project, Specification of the ELASTIC Demonstrators and Validation Plan (Deliverable D5.1), Zenodo, 2025. doi: 10.5281/zenodo.17590970 89 X. Xie, “Understanding the performance of eBPF-based applications”, thesis on ETH Zürich (tut. L. Brandner and G. Fragkouli), 2025 https://nsg.ethz.ch/files/public/theses/2024-benchmarking_ebpf_programs/thesis-1.pdf ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 68 - November 30, 2025 is given in the comparative analysis and performance evaluation by Budigiri et al., 90 and partially in later publications. 91 This paper proposes a method based on comparative latency and throughput measurements of network policies enforcement using eBPF (via CNI plugins) in intra-node and inter-node scenarios (Figure 14b). Figure 14. Comparative latency and throughput measurements of network policies enforcement using eBPF in Calico and Cilium. The infrastructure experimental setup has consisted of bare metal and OpenStack VM instances (master-slave architecture with two controller machines and droplets equipped with Intel(R) Xeon(R) CPUE5-2650 2.00GHz processors and 64GB RAM on Ubuntu, with each droplet having 16 CPU cores and two 10Gbit network interfaces) as benchmarks for both options. This is a common setup, similar to the one employed in the more recent thesis work referenced earlier,79 with a 10-core virtual machine on faster Xeon(R) CPUE5-2670 2.30GHz processors and increased cache sizes. At the low level, closer to native, performance (through latency and cache miss 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 exist between the types of maps used, threshold cache size, and additional complexity factors that affect the distribution of workloads across 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. 92 However, relatively little overall attention has been dedicated to these issues by now, which are expected to grow significantly with the spread of production-level solutions in 6G application scenarios. With the development and availability of emerging and maturing eBPF verifiers in addition to the core in-kernel ones, their comparative performance and evaluation benchmarking are also being explored. Recent initial efforts comparing PREVAIL to in-kernel versions, 93 as well as 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. 94 Finally, some emerging efforts in deployment performance monitoring/tracking explore the direction of 90 G. Budigiri, C. Baumann, J. T. Mühlberg, E. Truyen and W. Joosen, "Network Policies in Kubernetes: Performance Evaluation and Security Analysis", 2021 Joint European Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit), Porto, Portugal, 2021, pp. 407-412, doi: https://doi.org/10.1109/EuCNC/6GSummit51104.2021.9482526 91 D. Soldani et al., "eBPF: A New Approach to Cloud-Native Observability, Networking and Security for Current (5G) and Future Mobile Networks (6G and Beyond)," in IEEE Access, vol. 11, pp. 57174-57202, 2023 92 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 93 J.Lawall, M.Derri and K.Lazri, ”Performance evaluation of the Linux kernel eBPF verifier”, FOSDEM 2025 freeand opensource software community event, Brussels, https://fosdem.org/2025/schedule/event/fosdem-2025-6453-performanceevaluation-of-the-linux-kernel-ebpf-verifier 94 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 ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 69 - November 30, 2025 auditing of registered eBPF observability and performance overhead metrics values on the directly coupled DLT layer, like blockchain. 95 This aims to guarantee immutable tamper-proof traceability, with a potential to build 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. 3.2.4 Proposals and recommendations to overcome current limitations and to increase performance This section offers practical suggestions for enhancing the performance of eBPF deployments. Initially, it addresses the inefficiencies in process-to-process traffic redirection, as discussed in an earlier section of this document. Subsequently, it focuses on common best practices and guidelines applicable to eBPF deployments in general. 3.2.4.1 A proposal for using eBPF to accelerate end-to-end TCP performance on local connections Earlier in this document, Section 3.2.1 discussed a possible method for using eBPF to accelerate end-to-end TCP performance between local processes on the same kernel, a task of particular interest to service mesh and Kubernetes CNI implementations, as it would improve intercontainer networking speed. However, no relevant open-source project currently uses SK_MSG redirection for this purpose; instead, this feature is being discontinued (e.g., by the Cilium project) until its kernel implementation matures. In this section, we introduce an alternative way to achieve an equivalent goal by extending the eBPF capabilities of the Linux kernel. Developed within the ELASTIC component “Accelerated microservices interconnection” in WP2, the following is a preliminary presentation of the concept of a feature that will be discussed in more complete detail in the future Deliverable D2.3. Feature design. The objective of this effort is to improve application throughput when exchanging data over TCP connections between processes co-hosted on the same Linux kernel. To achieve this, the feature relies on an important observation: the TCP reliability guarantees are redundant in a fully local context, i.e., where traffic does not traverse physical networks, and instead remains completely enclosed within the bounds of the virtual network represented by the mesh of interconnected Linux network namespaces. In fact, packet drops and reorderings are typically caused by physical appliances’ buffers filling up, or improperly configured multipath environments. Within end-host systems, over-production of application data can be prevented at the source by throttling the producing socket, i.e., by blocking at the system call level. As a result, applications cannot overwhelm the kernel’s TCP stack and cause packet drops. 95 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 70 - November 30, 2025 Figure 15. Proposed high-level data path for TCP communications across containers sharing the same Linux kernel (red), compared to the current typical message journey in the same conditions (blue). Therefore, the adopted strategy is to skip applying the TCP layer for local communications, as depicted in Figure 15. While this is similar to the previously discussed SK_MSG redirection, our proposal takes a different approach: instead of requiring active intervention on a permessage basis to perform the redirection (as is necessary with SK_MSG operation), our TCP bypass technique offers ad-hoc, high-performance sockets for this scenario, instead adopting eBPF only in the control plane to set up the accelerated socket pair at connection-opening time. The rationale for this design choice is to reduce data plane overhead and support higher traffic speeds. Figure 16 shows how the control plane layer of the solution works. A BPF_PROG_TYPE_SOCK_OPS eBPF program intercepts connect operations on new TCP sockets (referred to as “active” in the figure); within the SOCK_OPS program, three existing bpf helpers are overloaded in the kernel to allow (i) looking up destination listening (“passive”) sockets in the system, and (ii) selecting one to complete the connection, bypassing all the usual steps involved in opening TCP connections, including the three-way handshake. Additionally, connections established in this way use the improved, direct data path of our custom technique, characterised by explicit knowledge of the peer socket’s kernel memory address, enabling direct data flow between the producer and consumer. Figure 16. Proposed control plane for our TCP-bypass technique. In the data plane, we currently rely on a custom, ring buffer-based implementation that trades memory consumption for performance, though other designs are also possible. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 71 - November 30, 2025 Additional details on the kernel modifications required to support this feature, eBPF code design, and performance improvements compared to both a TCP baseline and SK_MSG redirection will be studied in WP2 and presented in Deliverable D2.3. 3.2.4.2 Recommendations for improving eBPF deployment performance Improving the deployment performance of eBPF programs requires careful optimisation at both the program design level and within the execution environment. Prior work on Kubernetes CNIs has demonstrated that the structure of the datapath and the attachment point of ePBF programs within the packet-processing pipeline directly affect network latency and throughput. Measurements from comparative evaluations of Cilium and Calico show that Cilium’s eBPFbased datapath, which attaches programs at TC/XDP hook points on the veth interface, achieves lower request/response latency and higher throughput than iptables-based configurations, as it avoids parts of the traditional packet-processing chain 96 , 97 . These results indicate that positioning packet-processing logic earlier in the kernel networking path, thereby reducing the number of processing layers a packet must traverse, can yield significant performance benefits. Consequently, deployment strategies for latency-sensitive workloads should favour datapath designs that minimise unnecessary indirection and avoid combining multiple packet-processing mechanisms when a single, well-placed eBPF hook provides the required functionality. Another major source of deployment overhead lies in the design and use of eBPF maps. Recent benchmarking work highlights how map size, type, access frequency, and value layout directly affect cache locality and memory bandwidth utilisation 98 , 99 . Large PERCPU maps tend to increase cache footprint, while high-contention global maps can create lock bottlenecks on multi-core systems. Research also shows that misaligned map values and pointer-heavy structures significantly increase L3 cache misses and degrade program execution speed. To mitigate these issues, recommended practices include using PERCPU maps only for small percore state, storing read-dominant structures in shared HASH or LRU_HASH maps, and aligning map values to cache-line boundaries. In containerised deployments, networking parameters should be carefully tuned to ensure predictable and efficient eBPF performance. Studies of Kubernetes CNIs show that datapath designs using early kernel hook points and avoiding complex packet-processing chains achieve lower latency and higher throughput than traditional iptables-based routing. For latencysensitive workloads, it is therefore important to minimise indirect packet paths and unnecessary kernel-layer traversal. Finally, several studies emphasise the importance of systematic benchmarking and observability as part of the deployment pipeline. Combining microbenchmarking of map types and hook-level overhead with macrobenchmarking of complete data paths provides a more reliable view of real-world performance characteristics 100 , 101 . Furthermore, using eBPF-based observability tools to measure the overhead of eBPF itself enables early detection of regressions caused by kernel upgrades, map changes or program updates. 96 G. Budigiri, C. Baumann, J. T. Muhlberg, E. Truyen, and W. Joosen, “Network policies in kubernetes: Performance evaluation and security analysis,” in 2021 Joint European Conference on Networks and Communications and 6G Summit, EuCNC/6G Summit 2021, Institute of Electrical and Electronics Engineers Inc., Jun. 2021, pp. 407–412. doi: 10.1109/EuCNC/6GSummit51104.2021.9482526. 97 https://docs.cilium.io/en/stable/operations/performance/benchmark/ 98 X. Xie, L. Brandner, G. Fragkouli, and L. Vanbever, “Understanding the performance of eBPF-based applications.” 99 F. Shahinfar, S. Miano, A. Panda, and G. Antichi, “Demystifying Performance of eBPF Network Applications,” Proceedings of the ACM on Networking, vol. 3, no. CoNEXT3, pp. 1–21, Sep. 2025, doi: 10.1145/3749216. 100 M. Rezvani, A. Jahanshahi, and D. Wong, “Characterizing In-Kernel Observability of Latency-Sensitive Request-level Metrics with eBPF. 101 https://erthalion.info/2022/12/30/bpf-performance/ ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 72 - November 30, 2025 3.3 Static eBPF code security analysis This section presents the static eBPF code security analyser, which is one of the ELASTIC components designed to improve the eBPF code development support and developers’ experience. The creation of this component contributes to the realisation of the ELASTIC WP1 objectives O1.3 and O1.4, and realises 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. In this deliverable, the motivation, requirements, design, implementation, and testing of the tool are described, while the implications of this tool on a modular eBPF code architecture will be investigated in D1.3. A paper about the static eBPF code security analyser has been presented at the IEEE Cyber Security and Resilience (CSR) Conference. More details can be found in the paper 102 and in the GitHub tool repository. 103 3.3.1 Motivation and problem statement Writing safe and efficient eBPF programs requires developers to navigate a challenging interplay of kernel constraints, compiler optimisations, and strict verifier rules. Developers usually write the eBPF program source in C and compile it into the assembly-like language called eBPF bytecode, which is then analysed by the eBPF verifier during the loading of the program into the kernel space, through the bpf() system call or the libbpf library, in order to detect and stop loading potentially unsafe and insecure code. When the code does not pass this verification, the log messages returned by the verifier are difficult to understand, mainly because the verifier operates at a bytecode abstraction layer and returns logs that refer to 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 to product development. One last aspect to be considered is that the bugs that are continuously discovered in the eBPF verifier are witnessing the verifier’s limitations in preventing all potential security vulnerabilities that may be introduced in eBPF code. For this reason, extra checks may be necessary to achieve code verification with the highest security guarantees. All these aspects motivated the ELASTIC initiative to develop a static C code analyser capable of reporting at least the same issues found by the eBPF verifier, but with precise and easy-tounderstand error messages related to the original C source code, together with actionable suggestions to fix the discovered 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. 3.3.2 Requirements The requirements for the static eBPF code security analyser and are detailed below: 102 R. Rizza, R. Sisto and F. Valenza, "Design and implementation of a tool to improve error reporting for eBPF code," 2025 IEEE International Conference on Cyber Security and Resilience (CSR), Chania, Crete, Greece, 2025, pp. 214-219, doi: 10.1109/CSR64739.2025.11130075. 103 https://github.com/netgroup-polito/pretty-verifier ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 73 - November 30, 2025 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. 3.3.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. The most notable of such attempts 104 proposed 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 was based on a preliminary deep study of the eBPF verifier that has been done within T1.3 to determine the verifier’s detection and reporting capabilities, and to classify the security-related errors it can raise. This classification is also useful in order to have a reference for the evaluation of KPI 1.2. The preliminary study of the verifier mentioned above 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, assuming the code was compiled with the debug option. However, no file name and no line number are given, but only the string of the file 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 4. Table 4: 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 104 A. Mayer et al., "Composing eBPF Programs Made Easy With HIKe and eCLAT," in IEEE Transactions on Network and Service Management, vol. 21, no. 2, pp. 1359-1371, April 2024, doi: 10.1109/TNSM.2023.3325624. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 80 - November 30, 2025 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 108 and Wireshark. 109 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 110 (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. Figure 20. 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. While the figure only represents outbound traffic, received messages go through largely the same stack and are intercepted in equivalent positions. 108 “Tcpdump and Libpcap.” https://www.tcpdump.org/ (accessed Jun. 13, 2025). 109 “Wireshark: The world’s leading network protocol analyzer.” https://www.wireshark.org/ (accessed Jun. 13, 2025). 110 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.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 81 - November 30, 2025 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 D1.1, one of the main strengths of the eBPF ecosystem in Linux is its ability to not only enable programmability and extensibility of the LKNS, but also unlock powerful observability opportunities thanks to several eBPF program types which attach to 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 kernel infrastructure to attach eBPF probes to the network stack’s layer-4 reception and transmission code, in order to be “notified” whenever processes on the system were to read or write data over a transport-level stream socket. 2. Relying on eBPF networking primitives. Alternatively, network-specific eBPF infrastructure could also be used to intercept application traffic, though in order to respect our goal of lifting the capture to high-level L4 messages, packet-layer eBPF hook points such as TCX cannot be considered. Instead, Linux offers extensive socketlayer eBPF support, capable of attaching (and controlling) to most events involving sockets. For this specific use-case, the BPF_PROG_TYPE_SK_SKB and BPF_PROG_TYPE_SK_MSG program type pair were contemplated. They attach to socket maps and respond to message receive and transmit operations (respectively) performed on sockets added to the map. When SK_SKB and SK_MSG programs are invoked in response to a socket read or write, 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 type definitions of the Linux kernel, which are subject to change across versions. By contrast, special purpose networking hooks expose a stable API and can thus rely on longer stability guarantees. ● More streamlined interface to a wider set of functionalities: an SK_SKB/SK_MSG capture solution can be easily architected to support both TCP and UDP sockets. 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, i.e., option one in the above list. Ultimately, in fact, an early prototype based on using networking-specific hooks 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. This phenomenon was presented in Section 3.2.1, and can be summarised as being caused by the cost of the additional message copy in the data path, as well as the unconstrained ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 82 - November 30, 2025 amount of in-flight TCP data that can be accumulated in kernel buffers, breaking backpressure. 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 two BPF_PROG_TYPE_TRACING probes of type fentry and fexit, 111 and respectively attached to the tcp_sendmsg and tcp_recvmsg kernel functions, which represent the TCP-specific implementation of the socket send and receive operations. The probes perform a byte-level copy of the (possibly fragmented) message data into a ring buffer map. 112 The userspace component of the capture tool is a Rust library which continuously epolls the map’s file descriptor for readability; upon receiving a positive output from the epoll system call, the ringbuffer map is drained and all contained messages are served to the library’s user by invoking a pre-registered callback. In case lowest possible latency is desired over overall CPU efficiency, a busy polling solution could be developed as an alternative to the available epoll mechanism. To facilitate interoperability with TUC’s hardware IDS, a sample application is also provided within the capture library’s open-source repository. 113 The program is registered as a capture user, thus receiving all TCP inbound and outbound traffic in the system. Messages delivered through the callback function are then encoded and serialised into a BSON 114 stream containing all captured information, including source and destination IP addresses and ports, as well as the full message contents. Performance evaluation. Performance of the socket-level capture solution was measured and compared to that of tcpdump. To carry out a fair evaluation, both our tool and tcpdump were configured to write captured data to /dev/null in order to ignore possible I/O and filesystem-related bottlenecks. Tcpdump was additionally set up to perform packet filtering and discard non-TCP traffic to match the functionality of the ELASTIC solution. The test consisted in generating one synthetic, high-throughput TCP flow through a server’s loopback interface with iperf3, 115 then intercepting it with the two capture tools. Since both methods run the main in-kernel traffic interception and data copy inline with the network stack, capture overhead results in a slowdown of the iperf3 TCP flow rate. However, traffic capture also manifests through an additional performance metric in the form of dropped packets: drops occur when userspace processing of the captured data cannot keep pace with the delivery of received traffic from the kernel, thus leading to the overflow of packet queues. To avoid performance variability and randomness related to Linux scheduler-induced unpredictability, including possible Non-Uniform Memory Access (NUMA) domain data traversals in our multi-socket testbed, we pinned all participating processes to fixed CPU cores: iperf3 server and client threads were fixed to cores 2 and 4 using iperf3’s built-in affinity CLI argument, while tcpdump and our socket-level traffic capture tool were run on core 6 through explicit taskset assignment. Notably, by only using even cores, we avoid compute interference caused by multi-threading on our two-way SMT processor platform. Additionally, all tests were repeated ten times and the averages were collected to rule out run-to-run variance. 111 Similarly to kprobes, fentry/fexit programs can attach to arbitrary kernel functions, though they boast lower invocation overhead. 112 “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). 113 https://github.com/miolad/scap 114 https://bsonspec.org/ 115 https://github.com/esnet/iperf ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 83 - November 30, 2025 Table 5: Measured TCP throughput when intercepting loopback traffic with different capture solutions. Capture method TCP Throughput Drops Average message size No capture 62.3Gbps - - Tcpdump 37.4Gbps 0% 25940B Ours 50.1Gbps 0% 16380B As shown in Table 5, the performance of our socket-level traffic capture is 34% better than that of tcpdump, despite generating messages that are on average 37% smaller. Our solution is in fact currently configured with a maximum message size of 16kiB as a way to balance between CPU and memory overhead, while avoiding an extra data copy due to limitations in eBPF ringbuffer semantics. Additionally, both solutions achieve zero percent drop rates thanks to the /dev/null redirection, which effectively eliminates most userspace processing overhead, and allows this evaluation to focus on the in-kernel traffic capture performance. 3.4.2 Hardware AI-based IDS solutions Modern traffic capture systems focus on accurate, rapid, and adaptive intrusion detection capabilities. This section details the ELASTIC security defence framework, which targets the mitigation of at least 90% of known vulnerabilities in emerging 6G network infrastructures. The framework, developed to fulfil ELASTIC EO-KPI-9, combines high-fidelity kernel-level telemetry obtained through eBPF functionality with a hardware-accelerated, AI-enhanced Intrusion Detection System (AI-IDS). Together, these components provide fine-grained visibility into network workload behaviour, robust threat-detection capabilities, and adaptive responses suited to highly dynamic computing environments. The eBPF-based framework offers an efficient and lightweight mechanism for capturing network packets directly within the Linux kernel. By operating at the kernel level, eBPF can intercept packet flows with high precision and minimal overhead, eliminating the need for external monitoring agents. This in-kernel, real-time visibility facilitates the accurate extraction of traffic characteristics, connection metadata, and performance indicators essential for intrusion detection systems. Leveraging eBPF’s capability for dynamic tracing of socket activity and kernel events, the AI-IDS receives high-fidelity data streams that improve the reliability and accuracy of threat detection. Furthermore, the eBPF framework captures and forwards all network packets to the IDS, providing improved performance with reduced overhead and enabling traffic collection prior to service-mesh encryption, thus increasing overall system efficiency. Collectively, these properties position eBPF as a flexible, highperformance intermediary between network activity and the ELASTIC AI-IDS engine, strengthening both system observability and security effectiveness. The second tool that is combined under the proposed framework is the ELASTIC AI-IDS. The tool represents an advanced hardware-accelerated intrusion detection solution that combines the performance benefits of dedicated hardware with the enhanced analytical capabilities of artificial intelligence. Engineered to mitigate both contemporary and emerging cybersecurity threats—including previously unseen attack patterns—the ELASTIC AI-IDS architecture integrates low-latency hardware monitoring with sophisticated AI-based detection mechanisms. Its core functionalities encompass: (i) real-time data processing to enable immediate identification and mitigation of malicious activity, (ii) predictive analysis to forecast and adapt to evolving attack vectors, and (iii) high-precision detection of intrusion attempts, thereby significantly improving the reliability and effectiveness of modern network traffic monitoring systems. The ELASTIC AI-IDS is an innovative hardware/software solution integrating an FPGA-based IDS framework with machine-learning-driven threat analytics. The first component of this tool ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 84 - November 30, 2025 is a hardware implementation of a Snort 116 -derived pattern-matching engine—one of the most extensively utilised tools in network security. The proposed tool is deployed on a Xilinx Alveo U200 FPGA device, Figure 21, which is integrated in a high-end server. Specifically, the system features a lightweight software API operating on the host server, which is responsible for preprocessing and forwarding eBPF-derived traffic segments to the FPGA. Once data is received by IDS, the data are processed by a parallel, hardware-optimised pattern-matching architecture 117 , 118 , where multiple specialised modules operate concurrently on independent segments of the incoming data stream. This design enables line-rate inspection with minimal latency, making the system suitable for high-bandwidth 6G-relevant scenarios. Whenever a match against preloaded signatures is detected, the FPGA generates an alert and transmits the associated metadata back to the host, which forwards the information to the ELASTIC monitoring and decision-support components for further analysis and response. The second core element of the AI-IDS is the AI-driven signature adaptation module, which is tasked with the construction and the continual refinement of the signature database used by the FPGA-based IDS tool. Initially, the system is deployed with a baseline signature set derived from Snort rules, which serve as the foundation for the hardware-based pattern-matching engine. During operation, all traffic that is forwarded by the eBPF tool is processed by the hardware accelerator and is simultaneously analysed by a machine-learning model implementing an online semi-supervised learning strategy. Traffic segments classified as anomalous or potentially malicious are retained within a temporary dataset. At regular intervals, the system performs a training cycle on this dataset, enabling the model to extract new patterns indicative of emerging or previously unknown threats. The resulting refined signature structures are then converted into hardware-compatible representations and deployed onto the FPGAbased IDS framework. This adaptive learning mechanism supports real-time intrusion detection in highly dynamic and evolving environments, such as cloud infrastructures and IoT, aligning with the operational requirements of the ELASTIC framework. The mapped AI-based framework 119 is based on two semi-supervised algorithms, i.e., Convolutional Neural Network (CNN) and Long Short-Term Memory (LSTM), and it is currently under evaluation to determine the most effective mechanism for dynamic 6G environments characterised by heterogeneous devices and rapidly-evolving attack surfaces. 116 Roesch, Martin. "Snort: Lightweight intrusion detection for networks." Lisa. Vol. 99. No. 1. 1999. 117 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. 118 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. 119 Imani, F., Kargar, M., Assadzadeh, A., & Bayani, A. (2024, May). Integrating CNN-LSTM Networks with Statistical Filtering Techniques for Intelligent IoT Intrusion Detection. In 2024 8th International Conference on Smart Cities, Internet of Things and Applications (SCIoT) (pp. 189-195). IEEE. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 85 - November 30, 2025 Figure 21. ELASTIC tool integrating eBPF and AI-IDS for 6G network vulnerability mitigation. In this initial version of the tool, the workflow and the interoperability of the two ELASTIC tools, i.e., the eBPF-based framework and the AI-IDS tool, were tested and validated. The next steps will focus on extending the tool by incorporating additional functionalities from its integrated components. Specifically, while the current eBPF-based framework captures and forwards the entire network workload to the IDS, the final version will incorporate data-filtering capabilities to further improve overall system performance. Likewise, the current AI-IDS hardware module uses pre-trained AI-based intrusion detection models deployed on the hardware platform. Dynamic, workload-adaptive model training—enabling continuous model updates based on incoming network traffic—is planned to be introduced in T4.2. The following section presents an evaluation of the efficiency and performance of the current system using widely adopted, real-world network datasets. Performance evaluation. An initial evaluation of the performance and the operational efficiency of the proposed eBPF–AI-IDS framework was conducted on an ELASTIC server under realistic network workload conditions. The integrated system was evaluated using diverse network traffic types and multiple intrusion scenarios to examine its monitoring and detection capabilities. Two datasets were used to assess the performance of the eBPF/AI-IDS framework. The first dataset, IoT-23, 120 contains network traffic generated by Internet-of-Things devices infected with various forms of malware. It includes real-world malicious traffic captures that represent a broad range of compromised IoT device behaviours. The second dataset 121 focuses on Distributed Denial-of-Service (DDoS) attacks targeting supply-chain infrastructures. Specifically, it consists of UDP flood attacks initiated against remote hosts by transmitting high volumes of UDP packets. Both datasets aim to assess the system’s effectiveness when subjected to substantial malicious traffic loads. 120 Parmisano, A., Garcia, S., & Erquiaga, M. J. (2020). A labeled dataset with malicious and benign iot network traffic. Stratosphere Laboratory: Praha, Czech Republic. 121 Sharafaldin, I., Lashkari, A. H., Hakak, S., & Ghorbani, A. A. (2019,October). Developing realistic distributed denial of service (DDoS) attack dataset and taxonomy. In 2019 International Carnahan Conference on Security Technology (ICCST) (pp. 1-8). IEEE ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 86 - November 30, 2025 The validation scenario ran to verify the interoperability between the two ELASTIC components, eBPF and AI-IDS, followed the sequence of steps outlined below: 1. A virtual network interface for live data transfer was instantiated, enabling communication between the eBPF module and the AI-IDS component. 2. The eBPF tool received network packets in a streaming way using tcpreplay, which replayed traffic from the provided pcap datasets. The Rust-based eBPF program parsed incoming packets, processed them through its internal functions, and forwarded them in real time to the IDS component via the virtual network interface. 3. The AI-IDS component monitored the virtual interface, received the forwarded packets, and performed security analysis. 4. All detected security events were reported to the user through the terminal. All processing operations ran within a real-time streaming environment. Table 6 summarises the preliminary performance results obtained from the integrated ELASTIC eBPF and AI-IDS components when evaluated on the previously described network datasets. It is important to note that these results correspond to an initial integration stage: no parallelisation of incoming network-packet processing—such as multiple instantiations of the mapped tools—has been applied, nor have any additional performance optimisations been introduced. These enhancements will be incorporated in the final version of the proposed framework and will be reported in the final ELASTIC deliverables. Table 6: Preliminary performance evaluation results of the ELASTIC framework integrating eBPF with the AI-based IDS pipeline. Dataset Scenarios #Network Packets Processing Throughput Rate (Gbps) IoT-23 CTU-IoT-Malware-Capture-49-1 18111839 5.43 CTU-IoT-Malware-Capture-52-1 64503854 5.82 CTU-IoT-Malware-Capture-43-1 82108708 6.08 CTU-IoT-Malware-Capture-60-1 271150520 5.83 DDoS DDoS_attacks_0_249 85083037 5.49 DDoS_attacks_250_499 50885956 5.22 DDoS_attacks_500_749 78315443 5.05 3.5 Proposals and recommendations Through a thorough investigation, including literature review, analysis of public vulnerability repositories, and experimental activities, we analysed the status of eBPF from a security perspective, identifying the most significant attack surfaces, risks and potential countermeasures. Although eBPF provides powerful capabilities, it also introduces significant security risks that must be addressed with care. Current security mechanisms in the eBPF ecosystem remain immature, as evidenced by the frequent emergence of new CVEs and the increasing complexity of components, such as the verifier. While existing protections can prevent some vulnerabilities, they are far from comprehensive, making it essential to follow strict security practices. In this section, we identified the most important such practices. The most important one is keeping kernels updated, and when not possible, applying patches or hardening techniques— potentially using eBPF itself. The general principle of least privilege recommends granting eBPF programs the least privileges. At the same time, because of the recent proliferation of techniques for privilege escalation, container escape, and information leakage, also highlighted by our study, all the major Linux distributions have recently decided to disable unprivileged ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 87 - November 30, 2025 eBPF code by default to reduce the attack surface; we recommend that this same action be taken during the development of the ELASTIC HAL in T3.2. Another key recommendation arises from the fact that the most common vector for eBPFrelated CVEs is locally loaded malicious code. Therefore, we recommend application of supply-chain-security best practices, such as restricting eBPF programs to be loaded only from signed and verified sources. When eBPF code is developed rather than just used, it is important to prevent security vulnerabilities that may be inadvertently introduced and not blocked by the verifier, as discussed. This can be done by incorporating proper code auditing into the development pipeline, using state-of-the-art static code analysis tools specialised in identifying security vulnerabilities. This is particularly important when eBPF is used to implement security functions, and when eBPF programs process untrusted inputs, as with XDP. Finally, runtime monitoring of individual hosts running eBPF code (e.g., with eBPF-based tools like Falco and Tetragon) and of the network (e.g., with network IDSs like the one developed in ELASTIC) is recommended as a last line of defence, to identify intrusions that have not been blocked by the other protections. On individual hosts, eBPF hooks should be monitored for misuse, and network IDSs are recommended to detect anomalous traffic that might be generated by eBPF malware not identified by on-host monitors. Another related contribution is the development of Pretty Verifier, a static analysis tool for eBPF C code that can improve the developer's experience, providing explanation for the errors raised by the verifier and fix suggestions. Based on the results of our experiments that showed its effectiveness, the introduction of this tool in the development pipeline of eBPF C code in the ELASTIC ecosystem is recommended. When evaluating eBPF acceleration in the data-plane domain, our results show that although eBPF-based mechanisms can provide measurable benefits, the magnitude of these improvements greatly depends on the context. In the case of service mesh deployments, existing implementations devote a disproportionate amount of CPU cycles to packet encryption and decryption, thereby offsetting any potential speedup gained from migrating to eBPF-based data planes. Consequently, we recommend prioritizing features and infrastructure compatibility over the choice between eBPF-enabled or traditional networking stacks when selecting a service mesh platform. We also examined eBPF-based socket-level traffic redirection as a technique for improving host-local TCP throughput. The currently available BPF_PROG_TYPE_SK_MSG hook, together with its redirection primitives, enables transport-layer messages to be steered towards arbitrary TCP sockets, bypassing the conventional TCP/IP pipeline and most of the Linux network stack. However, expected performance improvements do not manifest in practice because SK_MSG redirection exhibits improper TCP backpressure behaviour. Based on this result, we recommend an alternative design to achieve accelerated traffic redirection that involves eBPF exclusively in the control plane, to be described in D2.3. The integration of the eBPF-based traffic capture solution with the ELASTIC hardwareaccelerated AI-IDS provides a robust basis for high-fidelity traffic monitoring and effective mitigation of 6G-relevant threats. To further enhance security, operational efficiency, and overall system performance, several architectural enhancements are recommended. The current eBPF subsystem forwards complete network data to the IDS, which introduces avoidable overhead and limits scalability. Introducing selective packet-filtering and early-discard mechanisms would significantly reduce traffic volume and increase throughput. Additionally, although the FPGA-based pattern-matching engine already provides low-latency, line-rate inspection, the AI layer remains dependent on static pre-trained models. Enabling continuous, workload-adaptive model training—combined with automated generation of hardwarecompatible signature formats—would enable rapid and proactive adaptation to emerging attack vectors and improve long-term detection accuracy. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 88 - November 30, 2025 Initial performance measurements also highlight the need for further enhancements to fully exploit the computational capacity of the underlying hardware. Increasing parallelism through multiple IDS instances and optimising host–FPGA data transfer mechanisms will be essential for achieving higher sustained throughput under realistic 6G traffic conditions. Also, for deployments involving high-sensitivity or latency-critical workloads, allocating dedicated accelerator resources to the IDS is recommended to minimise contention and reduce susceptibility to side-channel leakage. These enhancements, planned for the remainder of ELASTIC, are expected to decisively strengthen the robustness, scalability, and adaptability of the intrusion detection framework for next-generation networks. ELASTIC D1.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 89 - November 30, 2025 4 Conclusions and Next Steps This deliverable presents ELASTIC's work in executable isolation using Wasm and eBPF, including both analysis of the existing security landscape and new developments. These new developments include enhancements to the memory safety of applications in the Wasm sandbox, measurements of side-channel leakage from Wasm running in TEEs, new tooling for Wasm access control, component-model-aware notions of application identity for access control and attestation, protocols for atomic workload migration, a new static analyser for eBPF code, and an eBPF-based hardware-accelerated IDS. These contributions will directly form part of the ELASTIC framework, but also contribute to the technical development of ELASTIC components in this and other work packages: • In WP1, T1.4 will enhance the language support and component model support of technologies developed in WP1, including further development of our application identity analysis tooling, as well as investigation into methods for more portable eBPF development. This will allow us to more easily take these initial prototypes and integrate them into other applications, both within the ELASTIC demonstrators and in the broader Wasm and eBPF ecosystem. • In WP2, the results of our access control investigation, Wasm access control tooling, migration protocol, and side-channel security analysis will be incorporated into access control mechanisms and into the Propeller orchestrator. 122 • In WP3, Wasm will be incorporated into the HAL, and our Wasm binary analysis for application identity will be incorporated into the Remote Attestation implementation. • In WP4, the eBPF-based intrusion detection system from T1.3 will be applied to resource-limited edge platforms. • In WP5, the components from WP1 will be integrated with other ELASTIC technologies in order to instantiate the demonstrators: In Demonstrator 1, we will incorporate our Wasm application identity analysis for attestation. In Demonstrator 2, the Wasm flexible access control tooling from T1.2, and the migration protocol developed in T1.2 for migration of e.g. WASI resources. The eBPF data capture machinery is used already as a mechanism to capture data for use by the AI-IDS, for incorporation into both Demonstrators. The enhanced SSP will be used to compile Wasm components wherever possible. • In WP6, results will be incorporated into open-source projects and standardisation activities: we have begun engagement with the LLVM project about mainlining of the new Stack Smashing Protection implementation, and with the Wasmtime project about how to incorporate our work on application identity into the mainline Wasmtime, and potential interaction with the standard Wasm Component Model. 122 https://github.com/absmach/propeller. See also ELASTIC Project, Lightweight and Robust Orchestrating Mechanisms – Initial Version (Deliverable D2.1), Zenodo, 2025. doi: 10.5281/zenodo.15100798