Re: [PATCH] Add _FORTIFY_SOURCE implementation documentation [BZ #28998]

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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