[PATCH] Add _FORTIFY_SOURCE implementation documentation [BZ #28998]
Siddhesh Poyarekar
siddhesh@gotplt.org
Thu Dec 22 14:22:07 GMT 2022
On 2022-12-22 09:19, Siddhesh Poyarekar via Libc-alpha wrote:
> On 2022-12-22 08:35, Florian Weimer via Libc-alpha wrote:
>> * Siddhesh Poyarekar:
>>
>>> +The @code{_FORTIFY_SOURCE} macro may be defined by users to control
>>> +hardening of calls into some functions in @theglibc{}. This feature
>>> +needs a compiler that supports either the @code{__builtin_object_size}
>>> +or the @code{__builtin_dynamic_object_size} builtin functions. When
>>> the
>>> +macro is defined, it enables code that validates access to buffers that
>>> +are passed to some functions in @theglibc to determine if they
>>> +are safe. If the compiler is able to deduce the size of the buffer
>>> +passed to the function call but the call cannot be determined as safe,
>>> +it is replaced by a call to its hardened variant that does the access
>>> +validation at runtime. At runtime, if the access validation check for
>>> +the buffer fails, the program will terminate with a @code{SIGABRT}
>>> +signal.
>>
>> This doesn't really cover %n checks and the open checks, so it's
>> slightly misleading.
>
> How about the following then; I've mentioned %n in the description for
> level 2 so I'm only trying to provide a high level summary here:
>
> """
> If the compiler is able to deduce the size of the buffer passed to the
> function call but the call cannot be determined as safe, it is replaced
> by a call to its hardened variant that performs additional safety checks
> at runtime. At runtime, if those safety checks fail, the program will
> terminate with a @code{SIGABRT} signal.
> """
>
Uhmm, I just noticed that the open* checking is enabled at
__FORTIFY_LEVEL == 1, so I guess that description needs to change too.
Sid
More information about the Libc-alpha
mailing list