Skip to content
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

Closed
kuseni opened this issue Jan 20, 2015 · 12 comments
Closed

io.js starts slower than node.js on windows x64 #528

kuseni opened this issue Jan 20, 2015 · 12 comments
Labels
windows Issues and PRs related to the Windows platform.

Comments

@kuseni
Copy link

kuseni commented Jan 20, 2015

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

@reklatsmasters
Copy link
Contributor

iojs@1.0.2, outputs
1421785898254
1421785898347
~100ms

node@0.10.35, outputs
1421786140921
1421786140967
~40ms

@miketheprogrammer
Copy link

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.

@piscisaureus
Copy link
Contributor

This is mostly because the node.js apparently turned snapshots back on for their windows builds.
We could do that too- although snapshots are currently off for (questionable) security reasons.

@rvagg
Copy link
Member

rvagg commented Jan 22, 2015

hah... @piscisaureus perhaps I should reenable them in nightlies for a bit so we can let people test?

@Fishrock123
Copy link
Contributor

Fwiw the startup as tested by this is <1ms on OS X, io.js 1.0.3

@Fishrock123 Fishrock123 added the windows Issues and PRs related to the Windows platform. label Jan 22, 2015
@bnoordhuis
Copy link
Member

although snapshots are currently off for (questionable) security reasons

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.

@piscisaureus
Copy link
Contributor

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.

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.

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.

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.

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.

Most likely this is just a mistake.

@piscisaureus
Copy link
Contributor

@tjfontaine ^- any comment?

@bnoordhuis
Copy link
Member

The same seed is used throughout the entire process.

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.

The attacker would need to know exactly which build of node you're running.

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.

@piscisaureus
Copy link
Contributor

Looks like node is turning snapshots back off: nodejs/node-v0.x-archive@9e387fb...6168fe6

@bnoordhuis

Maybe that's true in joyent/node@v0.10 but that's not the case in io.js.

I can't point at a line of code but you're mistaken. The hash seed does end up in the snapshot.

@tjfontaine
Copy link
Contributor

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 Makefile, I've added a new rule for Node.js on windows that does the same. nodejs/node-v0.x-archive@6168fe6 This will be available in the next v0.10 release and subsequent, and we will be adding some post release tooling to verify what we can of that.

@piscisaureus
Copy link
Contributor

@tjfontaine
Thanks for your update.
Ben and I just had a small conversation about this. Io.js will disable snapshots by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

No branches or pull requests

8 participants