# Efficient Data Exchange between WebAssembly Modules
## 4 Karmem Approach
### Communication
#### 4.3.1 Code Generator  
Like other technologies such as FlatBuffers, Protobuf, and Cap'n'Proto, Karmem also requires a custom code generator, which enables the program to read and write data in a consistent layout while disregarding specific internal memory representations. Acting as a pre-compiler, it does not alter the generated bytecode or introduce new instructions or opcodes. Currently, the prototype can generate code for Go, Zig, and C, with plans to support Swift, Python, Odin, and Rust in the future. Language selection is based on popularity within the WASM scope [50], maturity of the supported compilers, and the programming language paradigm.  
Some programming languages can be difficult to implement and, in some cases, might offer limited features. To briefly mention some issues, Java, PHP, and JS cannot handle unsigned integers with a 64-bit size. Languages such as Java and C# use mark-and-compact garbage collectors, which can move the used memory, whereas Go uses a mark-and-sweep approach, but this might change in the future [51].  
Figure 15: Struct using example as array.  
The generated code can provide better performance and mitigate security issues. In the 2021 OWASP report, deserialization of untrusted data is listed among the top 10 security issues. It can lead to a potential application of logic abuse, denial of service, or arbitrary code execution, especially in PHP, Java, and C# [52; 53]. Oracle acknowledges that Java's serialization poses significant security risks. Indeed, it accounts for over one-third of its security issues [54] due to the nature of dynamic programming.  
While a sandbox like WASM can mitigate some security concerns, internal security checks, such as bound checks, remain essential to prevent unauthorized data access and application logic issues. However, the generated code cannot provide a native way to manage concurrent or conflicting access in a shared-memory region. That responsibility lies with the modules themselves, and non-parallel operation is the default.  
Unlike protocols such as WebStorage [55], Karmem does not treat stored and transferred data as confidential and sensitive by default. To prioritize performance, the generated code does not fully erase data between serializations and thus potentially allows access to partial or complete data through paddings and unused areas. The generated code supports in-place mutability of data, including resizing an array when it is smaller than the initially allocated capacity. In such cases, the code will only erase the remaining bytes of the last 512-bit block of the array to prevent SIMD instructions from reading potentially dirty data. However, any other data will not be erased, and it is the programmer's responsibility to evaluate if such action is required and can be performed manually.  
In a WASM environment, the host system is responsible for executing the guest code. Consequently, encryption and authentication of communication are useful in limited scenarios. However, in a networked environment, counter-based stream ciphers like ChaCha20 can be employed to encrypt data while maintaining the random-access capabilities of Karmem without requiring the decryption of the entire message. However, verifying the integrity and authenticity of the message may require analyzing the entire encrypted message.  
The generated code, particularly for the host, allows the programmer to specify a custom timeout to prevent resource exhaustion when running untrusted WASM modules, which will be later discussed in Section 4.3.3. However, synchronization features such as atomic operations over shared memories are not available and might cause undefined behavior. The host is solely responsible for the synchronization and schedule of execution of multiple concurrent guests.