Presenters

Source

Wham: Unleashing the Power of Performant, Sandboxed Instrumentation ✨🚀

Ever felt the pain of fragmented tooling when trying to understand your code’s inner workings? You’re not alone! The world of instrumentation, crucial for everything from debugging to security, has historically been a tangled mess of language-specific solutions. But what if you could write a tool once and deploy it across a multitude of environments with comparable performance? Welcome to the revolutionary world of Wham, an active research framework from Carnegie Mellon University that’s making this a reality! 🌐

Wham is here to tackle the tooling fragmentation that plagues developers and system administrators alike. Whether you’re diving deep into observability, enhancing developer experience with tools like flame graphs and test coverage, or needing to dynamically monitor production issues, instrumentation is your secret weapon. It also plays a vital role in platform resource management and even security by enforcing policies for untrusted code.

Why WebAssembly (Wasm)? The Secret Sauce 💡

Wham’s secret weapon? The incredible WebAssembly (Wasm) ecosystem! Two key aspects make Wasm the perfect foundation:

  • Polyglot Powerhouse: Wasm’s language-agnostic nature is a game-changer. It allows us to build language-agnostic tools, a core tenet of Wham’s mission. Imagine writing a single instrumentation tool that works seamlessly across Python, Rust, Go, and more! 🦀🐍
  • Managed Runtime Magic: Wasm’s managed runtime offers incredible portability across diverse hardware. Even better, the Wasm engine itself provides engine-level management of instrumentation, ensuring consistency and control.

Crafting Your Tools with Wham’s DSL ✍️

Wham introduces a powerful Domain-Specific Language (DSL) for defining your instrumentation tools. This isn’t about wrestling with low-level assembly; it’s about expressing your intentions clearly and concisely.

For instance, defining a “branch profiler” becomes elegantly simple. You can tell Wham to probe all Wasm BRF (branch if not zero) opcodes. The DSL allows you to:

  • Match Specific Wasm Opcodes: Target exactly what you need to observe.
  • Define Probe Logic: Specify what actions to take when a probe hits.
  • Manage State: Easily track variables like total and times_taken.
  • Report and Unshare: Use keywords like report to flush data and unshared for event-local state, giving you granular control.

Wham’s Architecture: Two Paths to Power 🚀

Wham’s architecture offers two primary compilation targets for your DSL-defined tools, each with its own strengths:

1. WAI Interface Target: Dynamic and Sandboxed 🛡️

This target generates a standalone .wasm tool that dynamically instruments your application at runtime.

  • High Observability: You gain access to bytecode and engine-level events (think Garbage Collection operations!), offering unparalleled insight.
  • High Performance: The Wasm engine’s optimizations ensure your instrumentation is lightning fast.
  • Sandboxed Environment: Your instrumentation runs in a secure, isolated space, minimizing intrusiveness.
  • Caveat: Portability is currently limited to WAI-compatible engines.

2. Bytecode Rewriting Fallback Target: Universal Reach 🌍

This target statically rewrites your application’s bytecode, weaving your instrumentation code directly into the application’s fabric.

  • High Portability: Works with any Wasm engine, making it incredibly versatile.
  • Limited Observability: You’re primarily limited to bytecode-level events.
  • Potential Intrusiveness: Since instrumentation isn’t sandboxed, it carries a slight risk of intrusiveness.

The beauty here is that switching between these targets often requires just changing the instrumentation target, truly embodying Wham’s “write once, deploy anywhere” philosophy.

Seeing Wham in Action: A Dynamic Call Graph Monitor 📊

A compelling demonstration showcased a dynamic call graph monitor built with Wham. This tool, expressed in the DSL, meticulously tracks direct and indirect function calls. The data is then conveniently flushed in CSV format.

This instrumented bytecode can be executed using either the rewriting or WAI target. A simple Python script then takes over, post-processing the data to visualize the call graph. This elegantly illustrates how Wham empowers you to build sophisticated monitoring tools with ease.

Performance That Impresses: Beyond Expectations 💨

Wham isn’t just about ease of use; it’s about serious performance. Initial unoptimized instrumentation might show overheads (like a 4.7x slowdown in a branch monitor evaluation). However, Wham’s optimization strategies are where the magic truly happens:

  • JITing the Tool: Compiling the instrumentation tool just-in-time dramatically slashes overhead.
  • Removing Expensive Runtime Calls: Streamlining operations further boosts speed.
  • Inlining Probe Callbacks: This advanced technique in the JIT can eliminate calls entirely, achieving impressive overheads as low as 1.6x!

Comparisons against hand-written, highly optimized Wasm bytecode for tasks like branch profiling and cache simulation reveal that Wham’s DSL-based approach achieves comparable performance. This is a monumental achievement, delivering top-tier performance without the manual toil of low-level coding.

The Low-Level Details: Optimizing the WAI Interface 🛠️

For the WAI interface, Wham employs sophisticated low-level optimizations:

  • Trampolines and Machine Code Stubs: Runtime calls are intelligently replaced with these efficient constructs.
  • Inlining Stubs in the JIT: Further eliminating calls and maximizing speed.

The Future is Bright: Cloud-Native, Security, and Beyond 🚀☁️

Wham’s journey is far from over. The team has ambitious plans:

  • Cloud-Native Applications: Extending instrumentation to the heart of modern cloud infrastructure.
  • Beyond Wasm: Exploring instrumentation for non-Wasm code, potentially integrating with powerful technologies like eBPF to target kernel events (e.g., Linux syscalls) via Kprobes. 👾
  • Security Policy Enforcement: A major focus is on using Wham for robust security policy enforcement and observability within Wasm components. This is particularly relevant for scenarios like service-level chaining where traditional network observability can be bypassed. Imagine an “observability layer” for runtime policy enforcement and data prominence! 🔒

Standardization and Collaboration: Building a Community 🤝

The Wham project is actively pushing for the standardization of the WAI interface to encourage broader engine adoption. They are also keen to collaborate and are actively seeking use cases to refine Wham’s feature set, including usage metering and advanced policy enforcement.

The research is detailed in a published paper, and the team warmly invites contributions and ideas via their GitHub issue tracker.

Q&A Highlights: Dynamic Instrumentation and Control Flow 🗣️

During the Q&A, a key question surfaced about dynamic instrumentation at the Wasm runtime level, drawing parallels to user-space probing tools like sysdig. The presenter confirmed that dynamic instrumentation is indeed supported on a specific research engine, with ongoing standardization discussions aiming to broaden these capabilities. A brief discussion on control flow instrumentation also occurred, with an invitation for further offline follow-up.

Wham represents a significant leap forward in making sophisticated instrumentation accessible, performant, and universally applicable. It’s a tool that promises to empower developers and security professionals alike, paving the way for more robust, observable, and secure software systems. ✨

Appendix