Good question! Nothing in SafeScript itself prevents it. Instrumenting the code to prevent this would be too costly. A script can do
var a = [];
for (var i = 0; i < 10000000; i++)
{ a.push({x: i}); }
But that’s because it’s up to the host to sandbox the script, eg in WebWorkers or Node VM Isolates, using Q.Sandbox and use Q.Proxy to transparently pass in the Facades.
In PHP the situation is excellent. That’s language has support for checking how much memory was used, so our injected checks already works there:
For native embedded applications, where SafeScript is positioned to replace Lua, the situation is quite good. QuickJS already has JS_SetMemoryLimit() - a hard byte ceiling, which throws when hit. In fact the https://github.com/SafeScript/safescript-quickjs repo already uses this.
You can think of this as the “belt-and-suspenders” approach. Perhaps a future version of SafeScript would instrument the actual imperative code to catch these, same as it catches a script that tries to peg the CPU. But so far, I haven’t found a good way, without totally overriding most Javascript primitives, objects and operations. Any suggestions?
It’s not the job of a language to solve everything. Sometimes the solution belongs in sandboxing and virtual machines. You should be isolating untrusted code anyway.
SafeScript was just inspired by Google’s CaJa project from 10 years ago. My Qbix Webserver started rewriting PHP before loading it, and I wondered what if I could start over and just reduce the language the way JSON reduced it to just data, and was wildly successful. I chose JS as the base because it’s everywhere. I then made it also execute inside PHP. I made it auto-await every promise so it could work in non-evented environments like vanilla PHP.
This could be the next Lua, for instance, but for the modern era and far safer.
Having said that… there may be some static analysis you could do, to conservatively overestimate how much memory any given program could waste, and reject those that COULD waste it. The nice thing about static analysis is you only have to run it once per particular script.
What you are saying here is completely different to what your GitHub readme says. You say it protects the host's environment there but here you say it actually doesn't so use a real sandbox.
> This could be the next Lua, for instance, but for the modern era and far safer.
It isn't the default but you can sandbox all of this with Lua already. Including limiting CPU and memory use.
What's stopping malicious scripts from sucking up the host's memory?
Good question! Nothing in SafeScript itself prevents it. Instrumenting the code to prevent this would be too costly. A script can do
But that’s because it’s up to the host to sandbox the script, eg in WebWorkers or Node VM Isolates, using Q.Sandbox and use Q.Proxy to transparently pass in the Facades.In PHP the situation is excellent. That’s language has support for checking how much memory was used, so our injected checks already works there:
https://github.com/SafeScript/safescript-phpFor native embedded applications, where SafeScript is positioned to replace Lua, the situation is quite good. QuickJS already has JS_SetMemoryLimit() - a hard byte ceiling, which throws when hit. In fact the https://github.com/SafeScript/safescript-quickjs repo already uses this.
You can think of this as the “belt-and-suspenders” approach. Perhaps a future version of SafeScript would instrument the actual imperative code to catch these, same as it catches a script that tries to peg the CPU. But so far, I haven’t found a good way, without totally overriding most Javascript primitives, objects and operations. Any suggestions?
Does the system do its own allocations with a memory block or does it basically depend on the host to malloc?
The system is basically JS, you can run it however you like!
SafeScript actually compiles to plain JavaScript, just like Typescript does
In PHP, it compiles to plain PHP :)
I think they're using a slightly different definition of "safe" than you are
It’s not the job of a language to solve everything. Sometimes the solution belongs in sandboxing and virtual machines. You should be isolating untrusted code anyway.
SafeScript was just inspired by Google’s CaJa project from 10 years ago. My Qbix Webserver started rewriting PHP before loading it, and I wondered what if I could start over and just reduce the language the way JSON reduced it to just data, and was wildly successful. I chose JS as the base because it’s everywhere. I then made it also execute inside PHP. I made it auto-await every promise so it could work in non-evented environments like vanilla PHP.
This could be the next Lua, for instance, but for the modern era and far safer.
Having said that… there may be some static analysis you could do, to conservatively overestimate how much memory any given program could waste, and reject those that COULD waste it. The nice thing about static analysis is you only have to run it once per particular script.
What you are saying here is completely different to what your GitHub readme says. You say it protects the host's environment there but here you say it actually doesn't so use a real sandbox.
> This could be the next Lua, for instance, but for the modern era and far safer.
It isn't the default but you can sandbox all of this with Lua already. Including limiting CPU and memory use.
Why are you trying so hard to defend programs that can crash by blaming it on their runtime environment?
I like the erlang philosophy of letting programs die if they crash.
The runtime environment handles those errors, not the code.
What?