search

realXtend / tundra

realXtend Tundra SDK, a 3D virtual world application platform.
www.realxtend.org
Apache License 2.0
84 stars 70 forks source link

Replace QtScript with V8 for Javascript execution. #542

Open peterclemenko opened 11 years ago

peterclemenko commented 11 years ago

qtScript is old, unsupported, and potentially insecure. It is also fairly slow compared to modern implementations. It would be wise to consider shifting to V8 for JS execution, which would be faster and allow for sandboxed execution.

peterclemenko commented 11 years ago

Also, this is related to #452 and #368.

antont commented 11 years ago

there is perhaps a bit of confusion here: qtscript is not a js engine, but a thing that uses a js engine. it can use V8 too, we haven't tested but it seemed fairly good last i looked (ages go), in a branch of qtscript.

anyhow using V8 directly is of course possible, similar to how e.g. Syntensity did it, and might be a way for us to cleanly implement clever optimizations (perhaps using array types, which has given great results on the py side with numpy and such).

feel free to make a V8Module for Tundra in a branch so we can see :) I tested with Lua once, was quite easy and nice.

erno commented 11 years ago

QtScript uses JavaScriptCore, Webkit's JS engine. In Qt 5 QtScript is in bugfixes-only deprecated mode and the new scripting engine uses V8. The new JS api needs investigating it can only happen after we sort out the rest of our Qt 5 story.

juj commented 11 years ago

th3flyboy: It is extremely important to back up these kind of comments "old, unsupported, potentially insecure, fairly slow", etc.. with details and proof. Otherwise, the comments will appear as opinions due to disfavorism, and easily look like FUD.

That being said, I generally agree with your points, and we are aware of the current and upcoming status of QtScript in Qt5. Here's the backing to these opinions:

As for security, I've found no reason to say that QtScript is inherently unsecure. We do have several bugs about security+QtScript, but most of them are caused by our use of QtScriptGenerator (http://code.google.com/p/qtscriptgenerator/), which is a project for which security is out of scope. However, given the amount of crash bugs we have in place today, we don't currently have a secure working script execution environment in place.

If someone can integrate a replacing script engine as a Tundra plugin, we'll be happy to take a look.

peterclemenko commented 11 years ago

Fair enough on all points. The main reason I bring up being unsecure is my knowledge of what happens to projects when they go unmaintained security wise. Someone will find a way to break it, and then all hell breaks loose because no one is fixing it. This is generally why you don't want to rely on projects that are unmaintianed or barely maintained for security, it's a never ending arms race, and someone will find a way to break it, and if it's not going to be supported, then it's going to be a massive target surface waiting to be hit.

Also, I was not aware it was just in depreciated mode and not flat out unsupported. My understanding was it was flat out unsupported and thus not being patched anymore. Bad intel on my part. And yes, I should have backed it up more, I didn't think to reference other bugs in the tracker when I did that.

As for implementing a scripting API, Lua is first on my list if/when I get around to scripting. I'll look at V8 after that.

jonnenauha commented 11 years ago

We'll your still throwing opinions/guesses to be honest :) "it will get unsecure now that it does not get commits anymore". We don't know that, I guess you can assume that if you want. We are in total control what gets exposed to our js code at the end of the day, we can remove Qt modules, classes, functions, properties from whatever, including out own QObjects. We blacklisted obviously terrible things to expose at some point and no one has really worked to sort out a complete list. I'm not even sure if that can be proven out right when its secure.

Crash bugs are another thing versus insecure calls that can remove C:\windows\x.dll from scripting. Crash bugs they have lots of and if you encounter one you'll just have to work around in in your js if possible.

Real script security in Tundra imo comes from who can make entities with script components to the scene, and define the script, and from what storage scripts are going to be executed. If this is done well then its the responsibility of those trusted people who can add the script to make it secure and not crash the client. We already have such system in Tundra which can achieve this kind of control.

@antont and @juj Has probably looked most at the V8 and other script implementation. Afaik Toni said the V8 would not even bring much more speed to the actual execution. And as it has been noted multiple times the slow part is getting complex objects from C++ to JS and back.

I would welcome some noticeably faster script language in addition to JS. You could then use this scripting to do more performance critical parts of your code, perhaps talk to it via the scene or entity actions. I could see this being a good choise. For our company having prolly 10-15k lines of Tundra javascript apps out in the world, I would very much like to avoid porting them to another implementation of JS or even some other language. JS is fine for most things, but when you get to the heavy lifting it would be nice to get a proper quick thing, that maybe would not even need UI etc. but just the basic API/scene access. This basic exposing we could maybe even handle by hand, if the language would not have proper qt bindings of custom QObject outside the actual Qt modules. Exposing the full Qt + our own OQbjects etc. would of course be madness :)

TL;DR; I think the current JS is secure enough when you combine logic that decides who can add scripts to the scene. Another faster language eg. Lua, would be a nice addition for coding your performance critical parts where the current JS has problems coping with.

peterclemenko commented 11 years ago

Personally, I'm more concerned about someone trying to smash the stack through JS or someone putting a backdoor in a 3rd party JS module, but for the most part, I understand the points you are making. The main concern I have about security isn't someone trying to mess with the scene, it's someone trying to gain a shell on a target system.

erno commented 11 years ago

Yeah, crash bugs can exploited in various ways to yield control over code execution. Stack smashing is one, there are many other types. Basically any time an attacker supplied data makes it to C++ and causes it to crash, there's a very high risk of a remote code execution vulnerability. Even NULL deref bugs.

antont commented 11 years ago

Jonne - using V8 directly and making the binding cleverly ourselves might well improve speed a lot, if we can do better in the c++ <-> js border than what currently happens with qtscript. I've just meant that because the bottleneck usually is in that interface, and not inside the js engine for js code, switching from JavaScriptCore to V8 while still using the qtscript mechanisms wouldn't probably change much.

About Lua, I tested a little with QtLua -- idea was also to check if that deals with the interfacing more efficiently, but I didn't get that far then (one evening). It is somewhat interesting as would give much of the Tundra APIs automatically (slots, properties, signals of QObjects such as Scene, Entity and IComponent) to Lua too, with the qt class metadata mechanisms.

erno commented 11 years ago

Qt 5's QJS seems to expose access to V8 API directly: https://qt.gitorious.org/qt/qtdeclarative/commit/6318f91dc0bf1ac428037c963b80b7a5d4e1ad30/diffs