[PATCH] pthread_cleanup_push macro generates warning when -Wclobbered is set

[Florian Weimer]

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