Request to update feature_test_macros(7) wrt FORTIFY_SOURCE

Request to update feature_test_macros(7) wrt FORTIFY_SOURCE

[Mingye Wang]

Hi,

It might be a good time to update the _FORTIFY_SOURCE bit in the
f_t_m(7) manpage. Specifically:

We currently have it stuck at level 2. Since level 3 is now a thing in
gcc and clang with the introduction of __builtin_dynamic_object_size,
we should add it. The language should be similar to the level 2
description, with the difference that level 3 is able to evalulate
dynamic sizes. There are two articles from Redhat about this new
level: one from when only clang had it[1], and the other from when gcc
added it too.[2].
[1]: https://developers.redhat.com/blog/2021/04/16/broadening-compiler-checks-for-buffer-overflows-in-_fortify_source#in_the_very_long_term__everything_is_dynamic
[2]: https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level

The other point relates to clang, in that we should mention that it
has it too since svn revision 55735 (2008). I will take some time to
track down the released version number. We also need to mention when
gcc and clang added the level 3 stuff.

I plan to send a patch on this stuff, but do be warned my man(7) and
git send-email are very rusty.

Regards,
Mingye Wang (Artoria2e5)

Re: Request to update feature_test_macros(7) wrt FORTIFY_SOURCE

[Alejandro Colomar]

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

Hi Mingye,

On 3/20/23 09:15, Mingye Wang wrote:
> Hi,
> 
> It might be a good time to update the _FORTIFY_SOURCE bit in the
> f_t_m(7) manpage. Specifically:
> 
> We currently have it stuck at level 2. Since level 3 is now a thing in
> gcc and clang with the introduction of __builtin_dynamic_object_size,
> we should add it. The language should be similar to the level 2
> description, with the difference that level 3 is able to evalulate
> dynamic sizes. There are two articles from Redhat about this new
> level: one from when only clang had it[1], and the other from when gcc
> added it too.[2].
> [1]: https://developers.redhat.com/blog/2021/04/16/broadening-compiler-checks-for-buffer-overflows-in-_fortify_source#in_the_very_long_term__everything_is_dynamic
> [2]: https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level
> 
> The other point relates to clang, in that we should mention that it
> has it too since svn revision 55735 (2008). I will take some time to
> track down the released version number. We also need to mention when
> gcc and clang added the level 3 stuff.
> 
> I plan to send a patch on this stuff, but do be warned my man(7) and
> git send-email are very rusty.

Thanks!  No problem about that.  Please CC some GCC or Clang mailing
list and related developers when you send your patch.

Cheers,
Alex


> 
> Regards,
> Mingye Wang (Artoria2e5)

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

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

[PATCH] feature_test_macros.7: document clang fortify support

[Mingye Wang]

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

Hi Alex,

It looks like Sam James has already documented level 3 of the macro.
The attached (no, git send-email is not happy with my proxy setup)
patch only adds some language related to clang. Here's to hoping the
system is happy with multipart mail.

I've CCed Erik Pilington, since he is the author of the LLVM-svn
352665, the change that introduced __builtin_dynamic_object_size() in
2019.

Regards,
Mingye Wang

[-- Attachment #2: 0001-feature_test_macros.7-document-clang-fortify-support.patch --]
[-- Type: application/octet-stream, Size: 1543 bytes --]

From b21bc416f0772b3c7783a1cb396cce5c0a170713 Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Wed, 22 Mar 2023 16:18:27 +0800
Subject: [PATCH] feature_test_macros.7: document clang fortify support

This commit lists both gcc and clang versions. It also happens to fix
the "glibc 4.0" mistake in b324e17d3208c940622ab192609b836928d5aa8d.

Signed-off-by: Mingye Wang <arthur200126@gmail.com>
---
 man7/feature_test_macros.7 | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/man7/feature_test_macros.7 b/man7/feature_test_macros.7
index 4dc9b9594..1c2719a80 100644
--- a/man7/feature_test_macros.7
+++ b/man7/feature_test_macros.7
@@ -655,15 +655,22 @@ For example, a program where
 size argument is variable
 can now be fortified.
 .IP
-Use of this macro requires compiler support, available with
+Use of this macro requires compiler support, available since
 .BR gcc (1)
-since glibc 4.0.
-.IP
+4.0
+and
+.BR clang (1)
+2.6.
 Use of
 .B _FORTIFY_SOURCE
 set to 3 requires
 .BR gcc (1)
-version 12.0 or later.
+version 12.0 or later, or
+.BR clang (1)
+version 9.0 or later, in conjunction with glibc 2.33 or later.
+.\" glibc is not an absolute requirement (gcc has libssp; NetBSD/newlib
+.\" and Darwin each have their own implementation), but let's keep it
+.\" simple.
 .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.40.0.windows.1

Re: [PATCH] feature_test_macros.7: document clang fortify support

[Alejandro Colomar]

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

Hi Mingye,

On 3/22/23 09:39, Mingye Wang wrote:
> Hi Alex,
> 
> It looks like Sam James has already documented level 3 of the macro.
> The attached (no, git send-email is not happy with my proxy setup)
> patch only adds some language related to clang. Here's to hoping the
> system is happy with multipart mail.
> 
> I've CCed Erik Pilington, since he is the author of the LLVM-svn
> 352665, the change that introduced __builtin_dynamic_object_size() in
> 2019.

Thanks!

> 
> Regards,
> Mingye Wang

> From b21bc416f0772b3c7783a1cb396cce5c0a170713 Mon Sep 17 00:00:00 2001
> From: Mingye Wang <arthur200126@gmail.com>
> Date: Wed, 22 Mar 2023 16:18:27 +0800
> Subject: [PATCH] feature_test_macros.7: document clang fortify support
> 
> This commit lists both gcc and clang versions. It also happens to fix
> the "glibc 4.0" mistake in b324e17d3208c940622ab192609b836928d5aa8d.
> 
> Signed-off-by: Mingye Wang <arthur200126@gmail.com>
> ---
>  man7/feature_test_macros.7 | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/man7/feature_test_macros.7 b/man7/feature_test_macros.7
> index 4dc9b9594..1c2719a80 100644
> --- a/man7/feature_test_macros.7
> +++ b/man7/feature_test_macros.7
> @@ -655,15 +655,22 @@ For example, a program where
>  size argument is variable
>  can now be fortified.
>  .IP
> -Use of this macro requires compiler support, available with
> +Use of this macro requires compiler support, available since
>  .BR gcc (1)
> -since glibc 4.0.
> -.IP
> +4.0

Please follow the style used since this commit:

commit b324e17d3208c940622ab192609b836928d5aa8d
Author: Alejandro Colomar <alx@kernel.org>
Date:   Sun Dec 4 20:38:06 2022 +0100

    Many pages: wfix
    
    Refer consistently to software versions.  In most cases, it is done as
    <software> <version>.  In the case of Linux and glibc, use the project
    name, instead of other terms such as 'kernel' or 'library'.
    
    I found the uses of inconsistent language with the following:
    
    $ find man* -type f \
    | xargs grep -i '\(since\|before\|after\|until\|to\|from\|in\|between\|version\|with\) \(kernel\|version\|2\.\|3\.\|4\.\|5\.\)' \
    | sort
    
    However, I might have missed some cases.  Anyway, 99% consistency is
    pretty good consistency.  We'll fix the remaining cases as we see them.
    
    Signed-off-by: Alejandro Colomar <alx@kernel.org>


That means, unformatted GCC 4.0 and Clang 2.6.

> +and
> +.BR clang (1)
> +2.6.
>  Use of
>  .B _FORTIFY_SOURCE
>  set to 3 requires
>  .BR gcc (1)
> -version 12.0 or later.
> +version 12.0 or later, or

Remove the "version" word.

Cheers,
Alex

> +.BR clang (1)
> +version 9.0 or later, in conjunction with glibc 2.33 or later.
> +.\" glibc is not an absolute requirement (gcc has libssp; NetBSD/newlib
> +.\" and Darwin each have their own implementation), but let's keep it
> +.\" simple.
>  .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.40.0.windows.1
> 


-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

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

Re: [PATCH] feature_test_macros.7: document clang fortify support

[Sam James]

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


Mingye Wang <arthur200126@gmail.com> writes:

> Hi Alex,
>
> It looks like Sam James has already documented level 3 of the macro.
> The attached (no, git send-email is not happy with my proxy setup)
> patch only adds some language related to clang. Here's to hoping the
> system is happy with multipart mail.
>
> I've CCed Erik Pilington, since he is the author of the LLVM-svn
> 352665, the change that introduced __builtin_dynamic_object_size() in
> 2019.
>

The patch looks OK to me in terms of the content, apart from the libssp
mention. libssp and stack smashing protection overall is distinct from
fortification.

SSP is where stack canaries are emitted and their value is checked
later on to see if they're intact. Fortification is where certain
functions are replaced with variants that check the size of their
arguments e.g. dst & src and ensure they're big enough. They're distinct.

> Regards,
> Mingye Wang
>
> [2. text/x-patch; 0001-feature_test_macros.7-document-clang-fortify-support.patch]...

best,
sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

[PATCHv2] feature_test_macros.7: document clang fortify support

[Mingye Wang]

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

Hi Alex,

Attached is the revised patch.

> That means, unformatted GCC 4.0 and Clang 2.6.

I've done that in the new version, but there are still a lot of ".BR
gcc (1)" in my version
of the tree from other pages. Are these to be changed in the future?

Best,
Mingye

[-- Attachment #2: 0001-feature_test_macros.7-document-clang-fortify-support.patch --]
[-- Type: application/octet-stream, Size: 1531 bytes --]

From a4d7290cff1ddfac1cd3b7ab5877e38987c4e774 Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Wed, 22 Mar 2023 16:18:27 +0800
Subject: [PATCH] feature_test_macros.7: document clang fortify support

This commit lists both gcc and clang versions. It also happens to fix
the "glibc 4.0" mistake in b324e17d3208c940622ab192609b836928d5aa8d.

Signed-off-by: Mingye Wang <arthur200126@gmail.com>
---
 man7/feature_test_macros.7 | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/man7/feature_test_macros.7 b/man7/feature_test_macros.7
index 4dc9b9594..5155f19ef 100644
--- a/man7/feature_test_macros.7
+++ b/man7/feature_test_macros.7
@@ -655,15 +655,15 @@ For example, a program where
 size argument is variable
 can now be fortified.
 .IP
-Use of this macro requires compiler support, available with
-.BR gcc (1)
-since glibc 4.0.
-.IP
+Use of this macro requires compiler support, available since
+gcc 4.0 and clang 2.6.
 Use of
 .B _FORTIFY_SOURCE
-set to 3 requires
-.BR gcc (1)
-version 12.0 or later.
+set to 3 requires gcc 12.0 or later, or clang 9.0 or later,
+in conjunction with glibc 2.33 or later.
+.\" glibc is not an absolute requirement (gcc has libssp; NetBSD/newlib
+.\" and Darwin each have their own implementation), but let's keep it
+.\" simple.
 .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.40.0.windows.1

Re: [PATCHv2] feature_test_macros.7: document clang fortify support

[Alejandro Colomar]

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

Hi Mingye,

On 3/24/23 07:07, Mingye Wang wrote:
> Hi Alex,
> 
> Attached is the revised patch.
> 
>> That means, unformatted GCC 4.0 and Clang 2.6.
> 
> I've done that in the new version, but there are still a lot of ".BR
> gcc (1)" in my version
> of the tree from other pages. Are these to be changed in the future?

If it's just a reference to the software, that is fine.  If it's a
reference to the version, then I want it to be greppable.

Cheers,
Alex

> 
> Best,
> Mingye

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

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

Re: [PATCHv2] feature_test_macros.7: document clang fortify support

[Mingye Wang]

Hi Alex,

On Sat, Apr 1, 2023 at 5:56 AM Alejandro Colomar wrote:
> If it's just a reference to the software, that is fine.  If it's a
> reference to the version, then I want it to be greppable.
>

Is my patch attached to the last message all good, or is there
anything more to do?

Thanks,
Mingye

Re: [PATCHv2] feature_test_macros.7: document clang fortify support

[Alejandro Colomar]

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

Hi Mingye,

On 4/3/23 18:24, Mingye Wang wrote:
> Hi Alex,
> 
> On Sat, Apr 1, 2023 at 5:56 AM Alejandro Colomar wrote:
>> If it's just a reference to the software, that is fine.  If it's a
>> reference to the version, then I want it to be greppable.
>>
> 
> Is my patch attached to the last message all good, or is there
> anything more to do?

Sorry about the delay; I'm a bit overloaded.  Did you check Sam's
objection?

On 3/23/23 06:38, Sam James wrote:
> The patch looks OK to me in terms of the content, apart from the libssp
> mention. libssp and stack smashing protection overall is distinct from
> fortification.
> 
> SSP is where stack canaries are emitted and their value is checked
> later on to see if they're intact. Fortification is where certain
> functions are replaced with variants that check the size of their
> arguments e.g. dst & src and ensure they're big enough. They're distinct.

Thanks,
Alex

> 
> Thanks,
> Mingye

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

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

Re: [PATCHv2] feature_test_macros.7: document clang fortify support

[Sam James]

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


Alejandro Colomar <alx.manpages@gmail.com> writes:

> [[PGP Signed Part:Undecided]]
> Hi Mingye,
>
> On 4/3/23 18:24, Mingye Wang wrote:
>> Hi Alex,
>> 
>> On Sat, Apr 1, 2023 at 5:56 AM Alejandro Colomar wrote:
>>> If it's just a reference to the software, that is fine.  If it's a
>>> reference to the version, then I want it to be greppable.
>>>
>> 
>> Is my patch attached to the last message all good, or is there
>> anything more to do?
>
> Sorry about the delay; I'm a bit overloaded.  Did you check Sam's
> objection?

I'm happy now after a clarification was made (libssp does more than I thought
it did).

>
> On 3/23/23 06:38, Sam James wrote:
>> The patch looks OK to me in terms of the content, apart from the libssp
>> mention. libssp and stack smashing protection overall is distinct from
>> fortification.
>> 
>> SSP is where stack canaries are emitted and their value is checked
>> later on to see if they're intact. Fortification is where certain
>> functions are replaced with variants that check the size of their
>> arguments e.g. dst & src and ensure they're big enough. They're distinct.
>
> Thanks,
> Alex
>
>> 
>> Thanks,
>> Mingye


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [PATCHv2] feature_test_macros.7: document clang fortify support

[Alejandro Colomar]

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

Hi Sam, Mingye,

On 4/5/23 03:53, Sam James wrote:
> 
> Alejandro Colomar <alx.manpages@gmail.com> writes:
> 
>> [[PGP Signed Part:Undecided]]
>> Hi Mingye,
>>
>> On 4/3/23 18:24, Mingye Wang wrote:
>>> Hi Alex,
>>>
>>> On Sat, Apr 1, 2023 at 5:56 AM Alejandro Colomar wrote:
>>>> If it's just a reference to the software, that is fine.  If it's a
>>>> reference to the version, then I want it to be greppable.
>>>>
>>>
>>> Is my patch attached to the last message all good, or is there
>>> anything more to do?
>>
>> Sorry about the delay; I'm a bit overloaded.  Did you check Sam's
>> objection?
> 
> I'm happy now after a clarification was made (libssp does more than I thought
> it did).

Thanks!  I applied the patch, with Acked-by: Sam James <sam@gentoo.org>.

Cheers,
Alex

> 
>>
>> On 3/23/23 06:38, Sam James wrote:
>>> The patch looks OK to me in terms of the content, apart from the libssp
>>> mention. libssp and stack smashing protection overall is distinct from
>>> fortification.
>>>
>>> SSP is where stack canaries are emitted and their value is checked
>>> later on to see if they're intact. Fortification is where certain
>>> functions are replaced with variants that check the size of their
>>> arguments e.g. dst & src and ensure they're big enough. They're distinct.
>>
>> Thanks,
>> Alex
>>
>>>
>>> Thanks,
>>> Mingye
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

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