On Tue, Dec 6, 2022 at 5:45 AM Jakub Jelinek <jakub@xxxxxxxxxx> wrote: > > On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote: > > On 05/12/2022 20:58, Ben Cotton wrote: > > > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to > > > improve mitigation of security issues arising from buffer overflows in > > > packages in Fedora. > > > > AFAIK, _FORTIFY_SOURCE=3 enables runtime checks for every mem*() function > > call. This should result in significant performance degradation. > > That is misunderstanding. > The way _FORTIFY_SOURCE works is that say for memcpy if the destination > has known upper bound on size (__builtin_object_size (dst, 0) returns > something other than ~(size_t)0), then __memcpy_chk is used instead of > memcpy, unless the compiler can prove that the length will always fit into > that destination (in that case it is folded back to (builtin) memcpy). > So, "every" is definitely not the case. In many cases nothing is known > about the size of the destination, and in a lot of cases it is provable that > no overflow will happen. To add to this, I twiddled the macros to make sure that even if the sizes are not known, we can infer safety from ranges of values that they could have. For example if the destination object size in memcpy is known to be at least 1024 bytes and the write size is known to be at most 64 bytes, the copy is deemed safe at compile time. > > To proposal owner: add information about potential performance degradation, > > including benchmark results. > > Deferring that to Siddhesh, I haven't done that benchmarking myself. I haven't run any benchmarks because (1) the magnitude of coverage is immense, making a small performance impact (IMO) worthwhile and (2) other distributions have enabled _FORTIFY_SOURCE=3 by default for nearly a year without any reports of performance degradation from their users and (3) the code size tests show negligible impact. However if it is considered a blocker by FESCO, I'll be happy to run a benchmark they suggest to post numbers. Thanks, Sid _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
