[PATCH] tst-setcontext10.c: Undef _FORTIFY_SOURCE

[Siddhesh Poyarekar]

On 2023-12-19 16:31, H.J. Lu wrote:
> On Tue, Dec 19, 2023 at 1:23 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-12-19 13:02, H.J. Lu wrote:
>>> When _FORTIFY_SOURCE is defined to 2, ____longjmp_chk is called,
>>> instead of longjmp.  ____longjmp_chk compares the relative stack
>>> values to decide if it is called from a stack frame which called
>>> setjmp.  If not, ____longjmp_chk assumes that an alternate signal
>>> stack is used.  Since comparing the relative stack values isn't
>>> reliable with user context, when there is no signal, ____longjmp_chk
>>> will fail.  Undefine _FORTIFY_SOURCE to avoid ____longjmp_chk in
>>> user context test.
>>
>> I don't remember the details, but ____longjmp_chk seemed to be a source
>> for false positives, enough for packages (ceph and python-cysignal IIRC)
> 
> Do they use user context?

That's the bit I don't remember.  I should take a look at this again 
next year.

>> to disable fortification altogether as a result.
>>
>> If this check is not reliable enough (I haven't had time to check) then
>> does it make sense to disable it altogether until we can make this check
>> more reliable?
>>
> 
> ____longjmp_chk doesn't work if user context is used.   In the meantime,
> I'd like to undef _FORTIFY_SOURCE in tst-setcontext10.c.
> 

I think that is fine.

Thanks,
Sid