build: enable v8's SipHash for hash seed creation#26367
build: enable v8's SipHash for hash seed creation#26367rvagg wants to merge 2 commits intonodejs:masterfrom
Conversation
|
If we are enabling siphash by default, should we acknowledge its LICENSE anywhere? |
|
Good question @richardlau, I would say that V8 needs to do that in deps/v8/LICENSE and then when we run ./tools/license-builder.sh it'll be pulled in. Feel like raising an issue against V8? |
deps/v8/gypfiles/v8.gyp
Outdated
There was a problem hiding this comment.
Ohh. We've been missing this with some of the other V8 new features...
/me writes himself a TODO note
|
does this warrant a patch bump? I don't know the rules there |
@targos ? P.S. Up till now we did bump |
If I'm reading https://github.com/nodejs/node/pull/25430/files#diff-75477e7cdd271be767e5255488ca45e1 correctly, siphash is not enabled by default in V8. |
|
@richardlau yes that's correct, I suspect because it'd be impractical, maybe impossible, to generate enough data to calculate the hash in a browser environment, especially now that they've got 64-bit seed length. It's slightly more practical when you have a server that will repeatedly answer you for hours on end. |
|
I'm in favor of not bumping the patch level when only gypfiles are changed |
|
Hash flooding is not considered an vulnerability in the browser's threat model. A browser needs to deal with arbitrary, possibly malicious code, but does not care much about a tab locking up. An infinite loop is a lot simpler, with the same result. V8 does not use it by default, and since it's a build-time flag, does not ship the code. That's why I included the I got some numbers here. The current implementation is referred to as "implementation 1". |
configure.py
Outdated
There was a problem hiding this comment.
For posterity: this could be just o['variables']['v8_use_siphash'] = b(options.without_siphash) but it's fine, it's still locally consistent.
There was a problem hiding this comment.
thanks for the tip, we could do a lot of simplification with that but I'll withhold this time
There was a problem hiding this comment.
Do we even need a ./configure flag?
IIUC this is an obscure enough configuration that doing:
./configure -- -Dv8_use_siphash=falseseems good enough
There was a problem hiding this comment.
It can be removed in a future version when someone's cleaning up. For now if it ends up causing problems, performance or backward compatibility, or whatever, at least they have an easy out
|
Thanks for the info @hashseed (and thanks for the hard work on this btw). I can get similar performance numbers using the benchmark in your doc with this turned on and off in Node, so at least I know it's enabled properly. I'm having a hard time finding anything in our benchmark suite that displays a meaningful difference though—there's a lot of I/O focus in our benchmarks and those that aren't I/O touch fairly deep code paths so are getting a lot of variety. Hopefully the overhead gets lost in the wash and will only hit a small subset of users. I've included the SipHash LICENSE in ours, unfortunately the CC0 text is 3 times the size of the code we're importing. |
LICENSE
Outdated
There was a problem hiding this comment.
IIUC CC0 is a "no-attribution no-copyright" license, which IMO makes explicitly including it counter productive.
IIUC CC0 is more of a "no copyright" waiver then a license, and as such does not require explicit attribution - https://wiki.creativecommons.org/wiki/CC0_FAQ#Does_CC0_require_others_who_use_my_work_to_give_me_attribution.3F I think it should be removed from |
|
I've removed the CC0 but left attribution, because we're good open source citizens: |
|
Landed in e1cd8ac...0d94c23 |
Triggers the V8_USE_SIPHASH to switch from the internal custom V8 hash seed generation function to an implementation of SipHash. Final step needed to clear up HashWick. PR-URL: #26367 Refs: #23259 Refs: https://darksi.de/12.hashwick-v8-vulnerability/ Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Yang Guo <yangguo@chromium.org> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
PR-URL: #26367 Refs: #23259 Refs: https://darksi.de/12.hashwick-v8-vulnerability/ Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Yang Guo <yangguo@chromium.org> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Triggers the V8_USE_SIPHASH to switch from the internal custom V8 hash seed generation function to an implementation of SipHash. Final step needed to clear up HashWick. PR-URL: #26367 Refs: #23259 Refs: https://darksi.de/12.hashwick-v8-vulnerability/ Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Yang Guo <yangguo@chromium.org> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
PR-URL: #26367 Refs: #23259 Refs: https://darksi.de/12.hashwick-v8-vulnerability/ Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Yang Guo <yangguo@chromium.org> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Notable Changes
* build:
* Enable v8's siphash for hash seed creation (Rod Vagg)
#26367
* crypto:
* Add `KeyObject.asymmetricKeySize` (Patrick Gansterer)
#26387
* deps:
* Upgrade openssl to 1.1.1b (Sam Roberts)
#26327
* process:
* Make `process[Symbol.toStringTag]` writable again
(Ruben Bridgewater) #26488
* repl:
* Add `util.inspect.replDefaults` to customize the writer
(Ruben Bridgewater) #26375
* report:
* Rename `triggerReport()` to `writeReport()` (Colin Ihrig)
#26527
Triggers the V8_USE_SIPHASH to switch from the internal custom V8 hash seed generation function to an implementation of SipHash. Final step needed to clear up HashWick. PR-URL: #26367 Refs: #23259 Refs: https://darksi.de/12.hashwick-v8-vulnerability/ Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Yang Guo <yangguo@chromium.org> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
PR-URL: #26367 Refs: #23259 Refs: https://darksi.de/12.hashwick-v8-vulnerability/ Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Yang Guo <yangguo@chromium.org> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Notable Changes
* bootstrap:
* Add experimental `--frozen-intrinsics` flag (Guy Bedford)
#25685
* build:
* Enable v8's siphash for hash seed creation (Rod Vagg)
#26367
* deps:
* Upgrade openssl to 1.1.1b (Sam Roberts)
#26327
* process:
* Make `process[Symbol.toStringTag]` writable again
(Ruben Bridgewater) #26488
* repl:
* Add `util.inspect.replDefaults` to customize the writer
(Ruben Bridgewater) #26375
* report:
* Rename `triggerReport()` to `writeReport()` (Colin Ihrig)
#26527
Notable Changes
* bootstrap:
* Add experimental `--frozen-intrinsics` flag (Guy Bedford)
nodejs#25685
* build:
* Enable v8's siphash for hash seed creation (Rod Vagg)
nodejs#26367
* deps:
* Upgrade openssl to 1.1.1b (Sam Roberts)
nodejs#26327
* process:
* Make `process[Symbol.toStringTag]` writable again
(Ruben Bridgewater) nodejs#26488
* repl:
* Add `util.inspect.replDefaults` to customize the writer
(Ruben Bridgewater) nodejs#26375
* report:
* Rename `triggerReport()` to `writeReport()` (Colin Ihrig)
nodejs#26527
Notable Changes
* bootstrap:
* Add experimental `--frozen-intrinsics` flag (Guy Bedford)
#25685
* build:
* Enable v8's siphash for hash seed creation (Rod Vagg)
#26367
* deps:
* Upgrade openssl to 1.1.1b (Sam Roberts)
#26327
* process:
* Make `process[Symbol.toStringTag]` writable again
(Ruben Bridgewater) #26488
* repl:
* Add `util.inspect.replDefaults` to customize the writer
(Ruben Bridgewater) #26375
* report:
* Rename `triggerReport()` to `writeReport()` (Colin Ihrig)
#26527
Notable Changes
* bootstrap:
* Add experimental `--frozen-intrinsics` flag (Guy Bedford)
#25685
* build:
* Enable v8's siphash for hash seed creation (Rod Vagg)
#26367
* deps:
* Upgrade openssl to 1.1.1b (Sam Roberts)
#26327
* process:
* Make `process[Symbol.toStringTag]` writable again
(Ruben Bridgewater) #26488
* repl:
* Add `util.inspect.replDefaults` to customize the writer
(Ruben Bridgewater) #26375
* report:
* Rename `triggerReport()` to `writeReport()` (Colin Ihrig)
#26527
Notable Changes
* bootstrap:
* Add experimental `--frozen-intrinsics` flag (Guy Bedford)
nodejs#25685
* build:
* Enable v8's siphash for hash seed creation (Rod Vagg)
nodejs#26367
* deps:
* Upgrade openssl to 1.1.1b (Sam Roberts)
nodejs#26327
* process:
* Make `process[Symbol.toStringTag]` writable again
(Ruben Bridgewater) nodejs#26488
* repl:
* Add `util.inspect.replDefaults` to customize the writer
(Ruben Bridgewater) nodejs#26375
* report:
* Rename `triggerReport()` to `writeReport()` (Colin Ihrig)
nodejs#26527
PR-URL: #26367 Refs: #23259 Refs: https://darksi.de/12.hashwick-v8-vulnerability/ Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Yang Guo <yangguo@chromium.org> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Enable the v8_use_siphash flag. This flag is enabled since Node.js v11.12.0 (2019-03-15), see linked PR, release notes, and the blog post detailing the attack. Ref: nodejs/node#26367 Ref: https://nodejs.org/gl/blog/release/v11.12.0/ Ref: https://darksi.de/12.hashwick-v8-vulnerability/
Triggers the V8_USE_SIPHASH to switch from the internal custom V8 hash seed generation function to an implementation of SipHash. Final step needed to clear up HashWick.
Ref: #23259
Ref: https://darksi.de/12.hashwick-v8-vulnerability/
This could arguably be semver-minor because it introduces a configure flag, but that doesn't show in
--help. I'm also unsure if this has any impact on snapshots, could it be breaking for people using snapshots for fast startup? (Electron projects do, don't they?).