Rendered at 01:45:42 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Rohansi 2 hours ago [-]
What's stopping malicious scripts from sucking up the host's memory?
EGreg 38 minutes ago [-]
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?
ranger_danger 1 hours ago [-]
I think they're using a slightly different definition of "safe" than you are
EGreg 24 minutes ago [-]
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.
ranger_danger 8 minutes ago [-]
Why are you trying so hard to defend programs that can crash by blaming it on their runtime environment?
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?
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.