Lessons-learned in porting libc-based legacy applications to WASI

WASM + WASI offers an unparalleled combination of security and portability. The best thing is that we can leverage this for existing applications. This talk covers the basic steps in porting a legacy application to WASI. It also highlights lessons learned from porting the PHP interpreter to WASI.

Any widely used libc-based application will be eventually ported to WASI (WebAssembly System Interface). In this talk we will explain why we think this is true and we will cover the basic things one needs to know about porting such legacy applications to WASI. We will spice it all with specific examples and lessons learnt from our work porting the PHP interpreter to WASI.

With WASM + WASI the same WASM application binary can run on a regular server, in a serverless environment, in a browser, or on an embedded device on the edge. And all of this will happen in a secure, capability-based sandboxed environment.

This promise is remarkably similar to what containers already offer to developers. Unfortunately, distributing an application with a container image will also carry the whole environment of the application, leading to huge data and memory footprints. WASM+WASI, on the other hand is about distributing just the binary and having the platform and runtime available on the target device.

Naturally, there is a catch. Building an existing application is straightforward with containers. However, it could get quite tricky or partially impossible with WASI, because WASI is a work in progress and does not yet offer parity to traditional system interfaces like POSIX or WIN32. But even in this situation, it can still be beneficial to port legacy code to WASI and use what is already provided.

We will talk about the environment setup and initial steps one usually takes when porting a libc-based application to WASI. Starting with wasi-libc and wasi-sdk, we will discuss the system features that are not yet there and the ones for which we can use a stub implementation from wasi-libc. This will be followed by approaches for writing our own stubs for missing functionality or turning off legacy code that relies on it.

The talk will move on to examples of how to run our ported WASM application with a runtime engine, comparing several runtimes, their configurations, specific features and options for debugging and optimization.

At the end we will share a few specific lessons which we learnt while porting the PHP interpreter to WASI.

At Wasm Labs at the VMware’s Office of the CTO, as part of our WebAssembly Language Runtimes project, we have been working on building WASM binaries for legacy language interpreters and some popular essential libraries. This led us to gather experience in what porting legacy code to WASI means and how to handle typical challenges there.

Each new legacy codebase that we take on has shown us that we will always have a lot to learn, but even what we can share so far is bound to save time, frustration, and money for anyone who decides to port some existing code base to WASI. Therefore, we are eager to share what we know and hopefully get back a response or more hints and tips from the audience in a follow-up discussion.