Hi Sam, On 10/13/22 20:57, Sam James wrote:
On 10/13/22 20:31, Sam James wrote:Reference: https://developers.redhat.com/blog/2021/04/16/broadening-compiler-checks-for-buffer-overflows-in-_fortify_source Reference: https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level Signed-off-by: Sam James <sam@xxxxxxxxxx> --- man7/feature_test_macros.7 | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/man7/feature_test_macros.7 b/man7/feature_test_macros.7 index d33041001..e62185745 100644 --- a/man7/feature_test_macros.7 +++ b/man7/feature_test_macros.7 @@ -643,9 +643,20 @@ and result in compiler warnings; other checks take place at run time, and result in a run-time error if the check fails. .IP +With +.B _FORTIFY_SOURCE +set to 3, additional checking is added to capture some functionWhat do you mean by "capture"?Maybe "capture" is not the best word. Maybe hooked / intercepted is better?
Yeah intercepted might be better.
F_S=3 lets cases where say, malloc size is based on a variable, still get detected because the compiler recognises such cases and adds scaffolding in to hook the functions.
Adding something like this to the page might be helpful.
(The malloc example at https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#1__a_new_builtin_provides_enhanced_buffer_size_detection is what I'm referring to). To be clear though: the semantics are similar to FORTIFY_SOURCE=2, it's just that FORITFY_SOURCE=3 uses an extra bit of information (__builtin_dynamic_object_size) to hook more cases.
Maybe this is interesting (although maybe a bit too much into implementation details.
I'd like to know, from the point of view of a user who knows little about the different fortify levels (that actually matches me quite well :), what would be the constant differences (i.e., ones that the compiler will respect in the future (if there are any). What kind of guarantees there are or not.
So whatever word works for FORTIFY_SOURCE < 3 works for 3 too. I'm definitely feeling like "capture" is not the best word but I'm struggling for the right one.
If you're not inspired now, I'm fine adding whatever you want to add now; and we can revise it in the future. That's fine.
-- Additional question: there's actually some confusing constraints about when we can use F_S=3. It needs GCC 12 or Clang 9 as a compiler, and >= glibc-2.34. musl does not, at this time, support any built-in fortification. I don't know if we should mention that part.
For sure. I was considering mailing musl maintainers to suggest that we could officially/consistently document musl, as it's become an important libc alternative in Linux distros.
Cheers, Alex -- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
