[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Comparing GCC and Clang security features

Comparing GCC and Clang security features

Posted Sep 13, 2019 11:52 UTC (Fri) by nix (subscriber, #2304)
Parent article: Comparing GCC and Clang security features

I see a possible synergy here with the not-yet-quite-designed CTF backtrace section code. The thing that makes -fsanitize=signed-overflow into a bloated pig is replicated warnings for signed overflow for every single potential overflow locus in the program. One can shrink that a lot by printfing the function name and line number separately from the constant text so the constant text can be deduplicated, but if some backtrace section somewhere (like, say, the only one I have any influence over :) ) could be used to map from address to rough idea of lineno in function and get function names even for static functions, one could use this to eliminate the non-deduplicable function name and lineno info too.

Just a thought, and barely even a woolly thought, certainly not anything like a *design* yet (I mean, I'm not even sure if it makes sense to encode even a vague guess at linenos in a backtrace section: it's not worth introducing them just for this, but if we might need them *anyway*, this could serve as another user: it seems unlikely but it might be true, so I'll keep this potential usecase in mind when I get back to the backtrace stuff).

Actually printing the warnings would still add repeated code at every locus, but at least not repeated big strings. Maybe, possibly, an improvement...


to post comments

Comparing GCC and Clang security features

Posted Sep 13, 2019 12:49 UTC (Fri) by eru (subscriber, #2753) [Link] (3 responses)

Back when compilers that checked things at run-time were popular, Intel included the single byte instruction INTO (interrupt if overflow flag set) into the x86 instruction set. I think it is still there. Using that the checking would have almost no effect on code size, if you can handle the resulting signal smartly.

Comparing GCC and Clang security features

Posted Sep 13, 2019 13:01 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

The code bloat here isn't really caused the overflow checks: those are fairly cheap. The problem is printing useful errors (including the locus of the problem) on error. Just a printf call is a lot bigger than the overflow checks, and the error-locus strings right now really explode the number of constant strings in the program.

Comparing GCC and Clang security features

Posted Sep 13, 2019 13:31 UTC (Fri) by eru (subscriber, #2753) [Link]

So using debug information is not an option? (Maybe that takes even more space).
How about something like what coverage instrumentation does? (Which includes adding some initialized constant data structures for each function).
For every function you would store the name, and an array mapping from the offsets of the overflow checks to line numbers. Not very much data there, since not every line needs to be mapped. I assume that after the trap there is some way to figure out the function where it happened and then find the map.

Comparing GCC and Clang security features

Posted Sep 25, 2019 20:38 UTC (Wed) by anton (subscriber, #25547) [Link]

INTO is not in AMD64. It has been replaced with one of the REX prefixes. However, a JO with a single-byte offset is also pretty small.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds