Re: [PATCH] feature_test_macros.7: document -D_FORTIFY_SOURCE=3

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3009 bytes --]

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@gentoo.org>
>>> ---
>>>   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 function
>>
>> What 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]