-
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
build: Add Stack-based Buffer Overrun Detection (-fstack-protector) #20928
Comments
The benchmark test result is as follows, I found buffers, string_decoder and url tests are impacted more or less, then I took 30 runs on them. I picked the most significant data from those results:
I did suggest to enable this flag, as linux kernel and chrome also enabled this. Balance security with performance are indeed a trade off. The thing I am wondering is whether this impact can be accepted? If yes I would prepare a PR for that. Thanks. |
That's a pretty steep performance drop. Can you post the full results? |
I didn't take a full benchmark for call cases with 30 runs, that seems too time costing. I just run all of the cases for about 3 runs, then choose the cases that have significant impacts and then I rerun those selected cases with 30 runs. I even removed some .js files and removed some configs by edit some js files, only focusing on the cases with significant impacts. So you may notice in my result there are few text than normal. Below is my results, if it's not enough, I could re-run more cases then. :)
result of benchmark/stirng_decoder:
result of benchmark/url:
|
Odd that two of the buffer benchmarks go up by 6 or 7%. In general the numbers look pretty bad though. A 1-2% drop might have been acceptable but this probably is not. This is with identical builds except for |
Yes, I also noticed some test even have performance improve, quite strange. |
this and our disabling of v8's untrusted code mitigations make me wonder if we should add like a "more security" option to our configure which enables these things at the cost of performance. |
@devsnek Yes, I also think a config option may be another choice for this kind of changes which is more flexible. |
While, based on latest findings that the Thanks for providing comments! @bnoordhuis @devsnek |
This issue is created to track the Stack-based Buffer Overrun Detection (-fstack-protector) suggestion from issue #18671 which included several different build flags.
The basic idea of Stack-based Buffer Overrun Detection building flag is to add a "canary" which is a
random number after the return address in the stack and check its value before returns to make sure it's not altered. Thus it could avoid a lot of stack buffer overflow attacks.
This could introduce more security but also performance lost, mainly because of the check of the canary. So, 3 different modes were provided to control how many functions are covered thus providing the trade off between security and performance. They are:
-fstack-protector
-fstack-protector-all
-fstack-protector-strong
.The
-fstack-protector-all
mode would affect every function and is not acceptable.The
-fstack-protector
protects functions that have a character array of eight bytes or more in length on its stack which seems too restrictive.The
-fstack-protector-strong
mode protects more functions than-fstack-protector
but not expand to all, so is a balance between-fstack-protector
and-fstack-protector-all
. Some info can be found here. However it's not supported in clang 3.4.2 (while it seems it's supported from clang 3.5.0 ).Maybe in future clang baseline increased to >= 3.5.0 we could have a try on
-fstack-protector-strong
. Currently we could focus on-fstack-protector
, and I am taking on the performance test on it to see its impact on performance and would make a PR if the result is acceptable.The text was updated successfully, but these errors were encountered: