search

facebookarchive / BOLT

Binary Optimization and Layout Tool - A linux command-line utility used for optimizing performance of binaries
2.51k stars 176 forks source link

Disable stack protection in runtime libraries #252

Closed yota9 closed 2 years ago

yota9 commented 2 years ago

In some of the system stack protection is enabled by default, which will lead in extra symbols dependencies, which we want to avoid.

Vladislav Khmelevsky, Advanced Software Technology Lab, Huawei

aaupov commented 2 years ago

Can you please elaborate the scenario in which these extra symbols create an issue (system/platform)?

lnicola commented 2 years ago

We found this in https://github.com/facebookincubator/BOLT/issues/217#issuecomment-970089077 (running BOLT on Rust programs on Arch Linux), but I don't know who adds the flag. cc1 -v lists -fstack-protector as disabled by default and -fstack-check=specific.

yota9 commented 2 years ago

Hello @aaupov ! On many linux distros the stack protection is enabled by default in compiler. In case it is enabled it will create some symbol dependensis e.g. stack_chk_guard, stack_chk_fail which are located in libc, so the binary usually will have them UND. Since the runtime libs are stand alone we don't want to create extra dependencies for them. We may add these symbols to the library, but actually I don't see the reason to support stack canary there, so I think just to disable it is good enough solution.

aaupov commented 2 years ago

Thanks @lnicola, @yota9! I wasn't aware of the libc dependencies, but I see now. Looks like we can't just pull __stack_chk_guard symbol into the library since it's supposed to be initialized at program load time. I guess that's enough of a reason to disable stack-protector for runtime libraries.

aaupov commented 2 years ago

Details of how stack_chk_guard, stack_chk_fail are used: https://access.redhat.com/blogs/766093/posts/3548631 (How does stackguard actually work)

yota9 commented 2 years ago

@aaupov We can do initialize it buy our selves. I mean we will have our own copy of the canary and fail function that the library will use, the other part of the code will still use LIBCs one. But I don't see the reason to do this. The canary is used for 2 things - security (not our case, since the instrumentation is not used on the production, although the hugify might) and the code debugging. The last one is a good thing, but although the instrumentation is not about performance, we want to keep the instrumentation code as fast as possible to get as much profile as possible, so in my mind it is OK not to use it here. Anyway the code is quite simple and compact, we just need to avoid VLA and alloca calls in it and everything should be fine :)

aaupov commented 2 years ago

77d5dcbd399fa64f05e296ed14d50ec6d43e231c