Content about #Mruby

Once we finished mechanisms like RPC, Handle, and Block, we already had a pleasant mruby scripting environment. But the most critical capability of a sandbox is “security” — every arbitrary script it runs should be treated as dangerous, which means we need to defend against all kinds of scenarios.

The Kobako: Handle Mechanism isn’t anything special for projects that support a scripting language, but blocks are a capability unique to Ruby, and it would be a shame if we couldn’t make good use of them inside a sandbox.

But can we really write something like this?

1sandbox.bind("Seq::Map", ->(items, &blk) { items.map(&blk) })
2sandbox.eval("Seq::Map.call([1, 2, 3]) { |x| x * 2 }").value
3
4# => [2, 4, 6]

Surprisingly, a block inside the sandbox can receive calls from the outside.

Kobako recently moved to v0.28.0, which reworked the design that used to depend heavily on MessagePack. It’s the first major revision since COSCUP wrapped up in August.

Still, as we head into next year’s (2027) AI applications, what capability is the Ruby ecosystem still missing? I think the answer comes back once again to the “Virtual Filesystem” I talked about with friends at RubyKaigi in Japan this April, so Kobako is about to support it as well.

In Kobako: Script Execution we walked through how a complete run is designed, but the current design still has some inconvenient spots. When we want to call a Ruby object from inside the sandbox, it’s hard to actually make use of the values it returns.

With standard output in place, whether a script runs correctly can finally be verified, which means we can start genuinely running Ruby inside Kobako’s sandbox environment.

Having sorted out the basic conditions for running mruby on WebAssembly, it’s time to start thinking about more practical uses. At the very least, a script should be able to run and print a message like Hello World, but mruby itself wasn’t designed with the WASI (WebAssembly System Interface) environment in mind, so many Gems simply can’t be used.

In Kobako: Exchanging Memory in WebAssembly we solved the problem of Ruby and WebAssembly interacting, and gave Ruby and mruby the ability to exchange values with each other, which basically cleared up the “sandbox” problem.

Kobako’s development is still at a very early stage, though, because there are plenty of problems that only show up in real use, and one of them is the problem of “deciding how to stop.”

The past few posts covered how MessagePack was chosen, but interacting through WebAssembly works a little differently from interacting with a native extension.

The reason is that what we’re building is a sandbox to isolate untrusted code, which means the operations are essentially close to one-directional. Code running inside the sandbox cannot touch any of the host’s memory, so the method calls we originally had in mind need some special handling.

Last weekend at COSCUP I gave a talk, “Let AI Take Over Your Application: Building a Seamless, Microsecond-Scale Ruby Sandbox,” covering some of the considerations behind Kobako’s design. During the Q&A afterwards, someone asked: in an era where AI makes the language matter less, why pick Ruby?

The short answer is simply “I like writing Ruby.” But there are much deeper considerations in how Kobako is designed.

Choosing mruby as the sandbox language came out of ruby.wasm’s limitations, but sharing the same language standard (ISO/IEC 30170:2012) with CRuby doesn’t mean the goal comes easily. Compared to CRuby, mruby comes with plenty of restrictions.

Those are the trade-offs mruby has to make to run in environments like embedded systems, and the lightweight nature that comes with them happens to be an advantage for an Embedded Sandbox. It turns the idea of embedding a Ruby sandbox into any language into a viable option.