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

zend_hash_do_resize: amortizing the cost of compaction #1199

Merged
merged 1 commit into from Jun 30, 2015

Conversation

4 participants
@kaja47
Copy link
Contributor

kaja47 commented Mar 26, 2015

New implementation of hashtables introduced a compaction step which is
triggered when a hashtable is full but it contains at least one deleted
bucket. Therefore there is a possibility that a cleverly crafted code can
trigger this compaction step (which takes time proportional to the size of
hashtabe) by executing constatnt number of operations. When the hashtable
is full, deletion and subsequent addition or single element triggers a
table compaction and these two steps can be repeated ad infinitum. This
might be avenue for a DOS attack.

This patch allows compaction to be performed only if the hashtable contains
at least 1/32 deleted elements, otherwise the hashtable is doubled in size.
Linear amount of work caused by compaction is amortized over multiple
malicious additions and deletions.

zend_hash_do_resize: amortizing the cost of compaction
New implementation of hashtables introduced a compaction step which is
triggered when a hashtable is full but it contains at least one deleted
bucket. Therefore there is a possibility that a cleverly crafted code can
trigger this compaction step (which takes time proportional to the size of
hashtabe) by executing constatnt number of operations. When the hashtable
is full, deletion and subsequent addition or single element triggers a
table compaction and these two steps can be repeated ad infinitum. This
might be avenue for a DOS attack.

This patch allows compaction to be performed only if the hashtable contains
at least 1/32 deleted elements, otherwise the hashtable is doubled in size.
Linear amount of work caused by compaction is amortized over multiple
malicious additions and deletions.
@MartinMajor

This comment has been minimized.

Copy link

MartinMajor commented Jun 30, 2015

This patch solves problem http://3v4l.org/5a6dO/perf#tabs where PHP7 is 20x slower than PHP5.

👍 for me

@php-pulls php-pulls merged commit b3962ab into php:master Jun 30, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@laruence

This comment has been minimized.

Copy link
Member

laruence commented Jun 30, 2015

merged, thanks , and also thanks to @MartinMajor bring this back :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment