CHC-based Automated Verification of WebAssembly Programs
This paper proposes an automated static verification method for a subset of WebAssembly using constrained Horn clauses, which effectively handles indirect function calls through type-based filtering and manages large panic handlers via control-flow analysis summarization.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine the internet as a giant, bustling city where every building is a website. For years, these buildings were built with a specific, heavy set of blueprints that made them safe but sometimes slow to construct. Then, a new, super-efficient language called WebAssembly arrived. It's like a universal, high-speed delivery drone system that can fly anywhere on the web, carrying heavy loads of code to run games, tools, and apps right in your browser. Because these drones are so fast and powerful, we need to make sure they never crash into a building or drop their cargo in the wrong place. This is the job of "verification"—a fancy word for mathematically proving that a program is safe before it ever runs.
To do this, computer scientists often use a tool called a "Satisfiability Solver." Think of this solver as a super-smart detective who can look at a set of rules and instantly tell you if a scenario is possible or impossible. If the rules say "The drone must be in the sky" and "The drone must be on the ground" at the same time, the detective knows that's a contradiction and the plan is unsafe. This paper takes that detective and teaches it how to understand the specific, tricky rules of WebAssembly, especially the parts that involve calling other functions indirectly and handling massive error messages.
The Mystery of the Shapeshifting Call
The authors, Akihisa Yagi, Ken Sakayori, and Naoki Kobayashi from the University of Tokyo, faced a tricky puzzle. WebAssembly programs are like a massive library where books (functions) can be pulled off the shelves dynamically. Sometimes, the code doesn't say "Open Book A"; instead, it says "Open the book at shelf number 5." This is called an indirect function call.
The problem is that if you try to check every single book in the library to see what might be on shelf number 5, the detective (the solver) gets overwhelmed. It's like trying to check every single possible combination of a million locks to find the right key. The naive approach would be to list every single possibility, but that creates a mountain of paperwork that no computer can solve in a reasonable time.
The authors' solution was to act like a very strict librarian. They realized that WebAssembly has a rule: you can only pull a book from the shelf if it matches the specific genre (type) you are looking for. So, instead of checking every book in the library, their method looks at the "genre" required at the call site and filters out all the books that don't fit. This drastically shrinks the list of candidates, making the detective's job much easier. They also added a second trick: if the library shelves are locked and never change (read-only), they can pre-calculate exactly which book is where, turning a complex puzzle into a simple list of "if this, then that" rules.
The Giant Panic Button
The second challenge was the "panic handler." Imagine a program that, when it makes a mistake, doesn't just stop; it launches into a massive, 10,000-step speech explaining exactly what went wrong, complete with diagnostic charts and error codes, before finally giving up. In WebAssembly, these panic handlers are huge blocks of code that are triggered when things go wrong.
For the safety checker, these massive speeches are a distraction. The only thing that matters is that the program eventually stops running safely (reaches an "unreachable" instruction). The long, winding path of constructing the error message doesn't actually change the fact that the program is crashing. However, if the detective tries to trace every single step of that 10,000-step speech, it gets bogged down.
The authors introduced a "summarization" technique. They realized that if a block of code is just leading up to a crash, they can cut out the middleman. They used a control-flow analysis to identify these long, winding paths and replaced them with a simple shortcut: "If you enter this room, you will eventually crash." It's like telling a tour guide, "Skip the 50-minute history lecture about the lobby; just tell us the exit is blocked." This keeps the verification focused on the critical safety issues without getting lost in the noise of the error message.
The Results: A Work in Progress
To test their ideas, the team built a prototype tool called WASMVERIFIER. They fed it 90 different programs, including some written in Rust and C, and asked it to prove they were safe.
The results were promising but not perfect. Using two different detective solvers (Z3 Spacer and Eldarica), the tool successfully verified or disproved the safety of about 54 to 56 programs. However, it hit a wall on about 20 to 22 programs, running out of time (a "timeout") or memory. In about 11 to 12 cases, it raised a "false alarm," thinking a program was unsafe when it was actually fine. The authors explain that these false alarms happened because their tool had to replace some unsupported instructions with a "crash" placeholder, which made the safety check too cautious.
The paper suggests that while this approach is a strong step forward for fully automated safety checks, it isn't a magic wand yet. The authors note that the method is still being refined, particularly in how it handles complex math on bits (bit-vectors) and how to deal with instructions it doesn't fully understand yet. They suspect the method is sound and complete, but they haven't written the formal mathematical proof for that yet, leaving that as a task for the future.
In short, the paper shows that by being smarter about how we filter indirect calls and by summarizing the messy parts of error handling, we can make automated safety checks for WebAssembly much more practical. It's a solid foundation, but the detective still needs more training to solve every case.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.