Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

OP, since you're here in the comments can you talk about the binary and memory size and sandboxing support? Ability to import and export functions/variables across runtime boundaries? Is this a feasible replacement for Lua scripting in a rust application?

View on HN

Hmm, sorry, I'm not sure what you mean.

The engine is written with a fair bit of feature flags to disable more complicated or annoying JS features if the embedder so wants: it is my aim that this would go quite deep and enable building a very slim, simple, and easily self-optimising JS engine through this.

That could then perhaps truly serve as an easy and fast scripting engine for embedding use cases.

That answers half my question (eg disable networking), thank you. The other part was about the overhead of adding this to an app (startup memory usage and increase in binary size) and how much work has been done on interop so that you can execute a static rust function Foo() passing in a rust singleton Bar, or accessing properties or methods on a rust singleton Baz, i.e. calling whitelisted rust code from within the JS env (vice-versa is important but that’s possible by default simply by hard-coding a JS snippet to execute, though marshaling the return value of a JS function without (manually) using JSON at the boundary is also a nice QOL uplift).

So for executing static Rust functions we do have "full" support via the `Value::BuiltinFunction` type. We have an internal "BuiltinFunctionBuilder" type for creating these conveniently (mostly) at compile time, and we have some external helper functions for creating them at runtime.

As for calling methods on a Rust singleton / struct, that is not yet really supported. We do have a `Value::EmbedderObject` type that will be the place for these, but its implementation is so far entirely empty / todo!() only. The first step for those will be just a very plain and simple `Box<dyn ObjectMethods>` type of thing, but eventually I'm thinking that our EmbedderObjects would actually become backed by an ECS data storage in the engine heap. So eg. your Bar type would be registered to the engine via some call together with its fields, and those would form an ECS "archetype". Then these items would be created by another call and would then become visible to JS code as objects, with some of their fields possibly being pointers to foreign heap data etc.

But that's a little ways off.

Thanks

> written with a fair bit of feature flags

I see you use Cargo feature for this. One thing to be aware of is Cargo's feature unification (https://doc.rust-lang.org/cargo/reference/features.html#feat...), ie. if an application embeds crate A that depends on nova_vm with all features and crate B that depends on nova_vm without any security-sensitive features like shared-array-buffer (eg. because it runs highly untrusted Javascript), then interpreters spawned by crate B will still have all features enabled.

Is there an other way crate B can tell the interpreter not to enable these features for the interpreters it spawns itself?

Nice catch, thanks for pointing that out! This also might be less than ideal if it’s the only option (rather than in addition to a runtime startup flag or a per-entrypoint/execution flag) because one could feasibly want to bundle the engine with the app with features x, y, and z enabled but only allow some scripts to execute with a subset thereof while running different scripts with a different subset.

Thank you for pointing this out, I'll have to look into this at some point.

There is currently no other way to disable features, and at least for the foreseeable future I don't plan on adding runtime flags for these things. I'm hoping to use the feature flags for optimisations (eg. no need to check for holes, getters, prototype chain in Array indexed operations if those are turned off) and I'm a bit leery of making those kinds of optimisations if the feature flags are runtime-controllable. It sounds like a possible safety hole.

For now I'll probably have to just warn (potential) users about this.

Reply on news.ycombinator.com