This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] pthread_cleanup_push macro generates warning when -Wclobbered is set
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Carroll <Paul_Carroll at mentor dot com>, libc-alpha at sourceware dot org
- Date: Tue, 14 Nov 2017 20:00:11 +0100
- Subject: Re: [PATCH] pthread_cleanup_push macro generates warning when -Wclobbered is set
- Authentication-results: sourceware.org; auth=none
- References: <3255e05c-196f-be61-799d-ad64828a721a@mentorg.com>
On 11/14/2017 07:05 PM, Paul Carroll wrote:
(f) On that basis, although it is a workaround for a compiler limitation
regarding diagnostic pragmas, adding volatile in pthread.h seems a
reasonable approach to avoiding the warning.
The problem is that this forces the function pointer onto the stack.
From tst-clobbered:
a6: 48 c7 44 24 20 00 00 movq $0x0,0x20(%rsp)
ad: 00 00
ab: R_X86_64_32S cleanup_fn
168: 48 8b 44 24 20 mov 0x20(%rsp),%rax
16d: 48 8b 7c 24 28 mov 0x28(%rsp),%rdi
172: ff d0 callq *%rax
Or tst-cancel1:
1f4: 48 c7 04 24 00 00 00 movq $0x0,(%rsp)
1fb: 00
1f8: R_X86_64_32S .text
2d8: 48 8b 04 24 mov (%rsp),%rax
2dc: 48 8b 7c 24 08 mov 0x8(%rsp),%rdi
2e1: ff d0 callq *%rax
2e3: 48 8d 7c 24 10 lea 0x10(%rsp),%rdi
2e8: e8 00 00 00 00 callq 2ed <tf+0x12d>
At least tst-cancel1 had a direct call before:
2a0: bf 2a 00 00 00 mov $0x2a,%edi
2a5: e8 56 fd ff ff callq 0 <cleanup>
This is problematic from a security point of view: We really do not want
unencrypted function pointers on the stack. (The setjmp return address
is at least mangled.)
Your test case already used an indirect call before the change with GCC
7. I think we should try to fix this in GCC. GCC 4.8 used to generate
a direct call here, so this is a minor regression in the area of
security hardening.
In the meantime, can you compile with -fexceptions?
Thanks,
Florian
PS: For those reading along, this is the GCC PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118