-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
io.js starts slower than node.js on windows x64 #528
Comments
iojs@1.0.2, outputs node@0.10.35, outputs |
I am not so sure that is a bad thing. I would be more interested to see the mem usage of both at startup, in combination with the speed of startup, and the percentage of processor usage. |
This is mostly because the node.js apparently turned snapshots back on for their windows builds. |
hah... @piscisaureus perhaps I should reenable them in nightlies for a bit so we can let people test? |
Fwiw the startup as tested by this is <1ms on OS X, io.js 1.0.3 |
I wouldn't say it's questionable. Turning on snapshots in release builds means that everything in the snapshot uses a single, known hash seed. Remember this thread? That's the kind of denial-of-service it makes possible. The one mitigating factor is that objects and strings created at run-time are still hashed with a random seed but that's essentially crossing your fingers and hoping that nothing from the snapshot is under the control of an attacker. If joyent/node enables snapshots just because it starts up a few milliseconds faster now, I'd say that's pretty darn irresponsible of them. |
I do remember. With "questionable" I meant that the security implications aren't necessarily that bad. The vulnerability is really hard to exploit and even if it works it's "only" a DOS attack. I think there are easier ways to DOS node. This is further mitigated that the hash seed is randomized every time node is built (with snapshot) or run (without snapshot). The attacker would need to know exactly which build of node you're running.
That's not true. The same seed is used throughout the entire process. The difference is is that when a snapshot is built the hash seed ends up in there. If a snapshot is not used the hash seed is generated when v8 starts up.
Most likely this is just a mistake. |
@tjfontaine ^- any comment? |
Maybe that's true in joyent/node@v0.10 but that's not the case in io.js, as far as I can tell: https://github.com/iojs/io.js/blob/f3fed51/deps/v8/src/heap/heap.cc#L5419-5428 If v0.10 uses a fixed seed throughout, that makes things even worse.
Most people run an official build or the binary from their distro vendor and won't be too far behind the latest stable release (no more than a year, say.) That's a fairly small range of versions and not too hard to automate detection/exploitation for. You or I could do it within an hour. |
Looks like node is turning snapshots back off: nodejs/node-v0.x-archive@9e387fb...6168fe6
I can't point at a line of code but you're mistaken. The hash seed does end up in the snapshot. |
Obviously just an oversight that unfortunately had gone unnoticed for awhile -- the unix builds all handle making sure the options are appropriately set the top level |
@tjfontaine |
Z:\bin\iojs-1.0.3>iojs -p "new Date().valueOf()" & iojs -p "new Date().valueOf()"
outputs
1421781086774
1421781086987
~ 200 ms diff
Z:\bin\nodejs-0.10.35>node -p "new Date().valueOf()" & node -p "new Date().valueOf()"
outputs
1421781064772
1421781064831
~ 60 ms diff
The text was updated successfully, but these errors were encountered: