Shulou(Shulou.com)06/01 Report--

This article analyzes "how to run WebAssembly in the Linux kernel". The content is detailed and easy to understand. Friends who are interested in "how to run WebAssembly in the Linux kernel" can follow the editor's train of thought to read it in depth. I hope it will be helpful to you after reading. Let's learn more about how to run WebAssembly in the Linux kernel with the editor.

Over the past few months, we have tried a variety of ways to speed up the Wasmer WebAssembly environment. These methods, including caching compiled code and implementing different levels of compilation back-end (Singlepass/Cranelift/LLVM), have also achieved good results.

These attempts to optimize performance lead us to consider a more "fundamental" question: what are the advantages of VM (virtual machine)-based programs over native programs? Can we make WASM run faster than native code?

The WebAssembly secure runtime environment that we implemented in the Linux kernel is described below. We successfully ran a TCP Echo server program in the Linux kernel and achieved a 10% performance improvement over the native code.

Background

"second operating system"

Many languages and runtime environments, including WebAssembly (supporting the implementation of WASI) and JavaScript (Node.js and browsers), are trying to build a second sandboxed "operating system" on top of the real operating system. However, this extra layer will bring a lot of performance loss.

As shown in the figure above, in such a traditional architecture, system service requests (system calls) from applications on VM need to pass through two layers of boundaries before reaching the kernel.

The performance loss of these two-layer boundaries is very large. A normal function call typically takes less than 5 ns, but a system call from within VM can take hundreds of nanoseconds.

The successor of Cervus

I wrote about a year ago about another WebAssembly "user mode" subsystem in the kernel-Cervus. At that time, neither WASI nor the "production level" WebAssembly runtime existed, but the Cervus project had proved that the idea was feasible and had great potential.

Now that the WebAssembly ecology is growing rapidly, it's time to make a complete kernel-mode WebAssembly runtime environment for real-world applications.

Why run WebAssembly in the kernel?

The main reasons are performance and flexibility.

WASM is a virtual instruction set protected by a virtual machine. We do not need to rely on external software / hardware protection to ensure security.

Running WASM in the kernel avoids the performance losses caused by these external protections, such as system calls (context switching), user mode / kernel state data replication, and so on.

At the same time, with the control of the underlying layer, we can implement many features that are inefficient or difficult to implement in user mode, such as direct access to hardware and handling intensive kernel events (such as network packet filtering).

Security.

Running user code in kernel mode is a dangerous thing. Although we have used a lot of techniques to protect the system from malicious code, we still recommend that trusted code be executed only through this module in the short term until we have complete Review runtime environment code.

Here are some known security risks and our responses:

Stack overflow: insert boundary check code during code generation

Memory access out of bounds: each WASM task is assigned the virtual address space of 6GB, so that cross-boundary access cannot be expressed.

The signal cannot terminate a process in the kernel state: after receiving the termination signal, set the WASM code page to NX to force execution to be terminated.

Kernel process floating-point state loss: manually save and restore floating-point state with kernel_fpu_ {begin,end} and preempt_notifier.

The kernel does not support Red Zone: avoid using it in code generators.

Examples and performance testing

We provide two examples: echo-server and http-server. They are located in the examples directory of the main Wasmer warehouse.

When using singlepass back-end compilation (generating x86-64 code directly without optimization) and testing with tcpkali/wrk locally, echo-server is about 10% faster than its user-mode equivalent implementation (25210 Mbps / 22820 Mbps) and http-server is about 6% faster (53293 Rps / 50083 Rps).

These two examples use WASI (file abstraction, console output) and our asynchronous network extension (through the kernel-net library).

You can read the code for these two examples and learn how to write high-performance network programs that run in kernel-wasm.

Compile, run

Before you load the kernel module, make sure that:

Your kernel version is greater than or equal to 4.15

Your kernel enables preemptive execution (preemption). Trying to execute WASM user code on a kernel that does not have preemption enabled will lock your system.

Kernel header files and build environment have been installed

First, clone Warehouse: https://github.com/wasmerio/kernel-wasm

Then execute make in the root directory of the repository and under the networking and wasi directories:

Makecd networking & & makecd.. / wasi & & makecd.

Load the module:

Sudo insmod kernel-wasm.kosudo insmod wasi/kwasm-wasi.kosudo insmod networking/kwasm-networking.ko

Select the singlepass backend and kernel loader when running Wasmer:

Sudo wasmer run-backend singlepass-loader kernel the_file.wasm

(cowsay running on kernel-wasm)

So much for sharing about how to run WebAssembly in the Linux kernel. I hope the above content will improve everyone. If you want to learn more knowledge, please pay more attention to the editor's updates. Thank you for following the website!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.