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

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

[Sam James]

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
+calls used with an argument of variable size.
+.IP
 Use of this macro requires compiler support, available with
 .BR gcc (1)
 since version 4.0.
+.IP
+For use of
+.B _FORTIFY_SOURCE
+set to 3, then
+.BR gcc (1)
+version 12.0 or later is required.
 .SS Default definitions, implicit definitions, and combining definitions
 If no feature test macros are explicitly defined,
 then the following feature test macros are defined by default:
-- 
2.38.0

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

[Alejandro Colomar]

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

Hi Sam,

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"?

Cheers,

Alex

> +calls used with an argument of variable size.
> +.IP
>   Use of this macro requires compiler support, available with
>   .BR gcc (1)
>   since version 4.0.
> +.IP
> +For use of
> +.B _FORTIFY_SOURCE
> +set to 3, then
> +.BR gcc (1)
> +version 12.0 or later is required.
>   .SS Default definitions, implicit definitions, and combining definitions
>   If no feature test macros are explicitly defined,
>   then the following feature test macros are defined by default:

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]



> On 13 Oct 2022, at 19:50, Alejandro Colomar <alx.manpages@gmail.com> wrote:
> 
> Hi Sam,
> 
> 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?

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.

(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.

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.

--
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.


> Cheers,
> 
> Alex

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

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

[Alejandro Colomar]

[-- 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 --]

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

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]



> On 13 Oct 2022, at 20:12, Alejandro Colomar <alx.manpages@gmail.com> wrote:
> 
> Hi Sam,

Hi!

> 
>>> [snip]
>>> 
>> Maybe "capture" is not the best word. Maybe hooked / intercepted
>> is better?
> 
> Yeah intercepted might be better.
> 

Done.

>> 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.

I've put it in -- please let me know if it's helpful as-is or not.

> 
>> (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'll leave this part out for now, but keep the reference in the commit message.

> 
> 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.
> 

What do you think about the latest state (I'll send v2 now)?

It's hard because it's reliant on what the compiler can deduce,
but the general idea is that it can go a step beyond and try to come
up with an upper bound based on a variable, even if it can't
get the exact size right, so it at least knows if you overshoot by a lot
now.

>> 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.
> 

I think this is a good idea. They might say the POSIX man pages should serve as documentation
enough, but I think specifically documenting it will be useful -- not just for this fortification bit,
but another example is actually time64 -- musl made a hard break in 1.2.x, hence no need
for macros.

I feel like that sort of information is useful for people so you have my full support in that
and I'm happy to help.

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]