[HN Gopher] GCC's new fortification level: The gains and costs
___________________________________________________________________
GCC's new fortification level: The gains and costs
Author : fanf2
Score : 70 points
Date : 2024-06-24 11:42 UTC (2 days ago)
(HTM) web link (developers.redhat.com)
(TXT) w3m dump (developers.redhat.com)
| loeg wrote:
| (2022)
| Someone wrote:
| It also doesn't deliver what it promises, as it doesn't discuss
| the cost well. The only thing it states is that it increases
| code size, but it doesn't given give numbers, and the header
| _"The gains of improved security coverage outweigh the cost"_
| doesn't describe its content, which says:
|
| _"We need a proper study of performance and code size to
| understand the magnitude of the impact created by
| _FORTIFY_SOURCE=3 additional runtime code generation. However
| the performance and code size overhead may well be worth it due
| to the magnitude of improvement in security coverage."_
| RustyRussell wrote:
| Yes, came here to say this too. Of course it varies, but some
| measurements would be nice!
| rdtsc wrote:
| Just curious, does anyone run with _FORTIFY_SOURCE=3 in
| production? Did you catch any overflows because of it, and most
| importantly, is there a noticeable performance degradation?
| 9659 wrote:
| This brings up a question. I think we can all agree that
| detecting an overrun shows a fault in the system. But does it
| create an error?
|
| Could this could be changed to where the overflow does not
| cause an abort; rather the next read of that location, without
| a corresponding legal write causes the abort. A buffer overrun
| does not mean the answer is wrong, but the use of memory that
| was overrun will.
|
| In that case, production or not, you would want an abort. The
| answer is wrong!
|
| (Perhaps this makes no sense. If so, sorry, the idea just came
| to me after reading the article.)
| lmm wrote:
| Overrunning the buffer means your program's behaviour is
| undefined. Continuing to function at all, much less doing
| what you wanted, merely means you got lucky with the compiler
| this time.
| forbiddenlake wrote:
| Arch Linux switched to it last year
|
| https://rfc.archlinux.page/0017-increase-fortification-level...
| jupp0r wrote:
| I would imagine false positives could be a huge problem. The
| behavior if a violation is detected is to gracefully terminate
| the program, so you could end up with more (but less exploitable)
| crashes than without FORTIFY_SOURCE.
| jupp0r wrote:
| Just to clarify: false positives in the sense that memory
| safety is violated intentionally as described in the article
| with relation to realloc and similar hacks, which would
| normally not cause problems.
| ngneer wrote:
| I would encourage the community to find a unit of measurement for
| security. Every defense can be breached, so every defense has an
| active region, much like transistors. Question is how to
| quantify.
| o11c wrote:
| The `realloc` problem isn't the only one - it also breaks many
| formerly-well-defined programs that use `malloc_usable_size`.
|
| Instead of fixing this, the developers behind the "dynamic object
| size" push have been _changing the documentation_ to declare any
| use of `malloc_usable_size` buggy even though it used to be
| explicitly documented as safe.
|
| I suspect that GCC's optimization passes will break even
| C-standard-compliant use of `realloc`, similar to how ASAN can
| break due to dynamic equality checks between pointers of
| different provenance.
|
| Life would be _much_ simpler for many of us if the standards
| committee bothered to standardize a function that says "give me
| a buffer of semi-arbitrary size and tell me how big it is; I
| promise to resize it later", which is _very_ widely intended. An
| explicit "realloc in place only, else fail" would also make many
| more useful programs feasible to write.
___________________________________________________________________
(page generated 2024-06-26 23:00 UTC)