On Thu, Feb 15, 2024 at 10:53:08PM +0000, Sam James wrote:
> With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's
> __vfprintf_chk ends up calling __vprintf_chk rather than vprintf.
s/__vprintf_chk/__vfprintf_chk/ above
>
> ```
> --- a/fortify.s
> +++ b/no-fortify.s
> @@ -8,27 +8,28 @@
> [...]
> __vfprintf_chk:
> [...]
> movl $1, should_optimize(%rip)
> - jmp __vfprintf_chk
> + jmp vfprintf@PLT
> ```
>
> 2024-02-15 Sam James <s...@gentoo.org>
>
> gcc/testsuite/ChangeLog:
> * gcc.c-torture/execute/vfprintf-chk-1.c (__vfprintf_chk): Undefine
> _FORTIFY_SOURCE
> to call the real vfprintf.
I think we should change vprintf-chk-1.c as well.
> ---
> The test, AIUI, is trying to test GCC's own basic _chk bits rather than
> any of e.g. glibc's _FORTIFY_SOURCE handling.
>
> I'm curious as to why only vfprintf triggers this right now. If this patch is
> right,
> perhaps we should do printf-chk-1.c, fprintf-chk-1.c, and vprintf-chk-1.
That is easy. In the printf-chk-1.c case it calls vprintf which results in
__vfprintf_chk or __vprintf_chk calls but redefines just __printf_chk.
Similarly fprintf-chk-1.c case calls vfprintf which results in __vfprintf_chk
call which isn't redefined either.
In the __vfprintf_chk case it calls vfprintf, which the inline results in
__vfprintf_chk call and so it self-recurses instead of calling glibc for the
actual implementation.
In the vprintf-chk-1.c case, it depends.
__fortify_function int
vprintf (const char *__restrict __fmt, __gnuc_va_list __ap)
{
#ifdef __USE_EXTERN_INLINES
return __vfprintf_chk (stdout, __USE_FORTIFY_LEVEL - 1, __fmt, __ap);
#else
return __vprintf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __ap);
#endif
}
So, if __USE_EXTERN_INLINES is defined, it will work fine, if not, it will
also self-recurse like vfprintf-chk-1.c.
Jakub
