Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1408547

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

Show all headers | View raw

From: Nick Alcock <nix@esperi.org.uk>
Date: Fri, 27 May 2016 14:19:27 +0100

> The only difference between the two series above is that in the crashing
> series, the ka_restorer stub functions __rt_sigreturn_stub and
> __sigreturn_stub (on sparc32) and __rt_sigreturn_stub (on sparc64) get
> stack-protected; in the non-crashing series, they do not; the same is
> true without --enable-stack-protector=all, because the functions have no
> local variables at all, so without -fstack-protector-all they don't get
> stack-protected in any case. Passing such a stack-protected function in
> as the ka_restorer stub seems to suffice to cause this crash at some
> later date. I'm wondering if the stack canary is clobbering something
> that the caller does not expect to be clobbered: we saw this cause
> trouble on x86 in a different context (see upstream commit
> 7a25d6a84df9fea56963569ceccaaf7c2a88f161).
> 
> It is clearly acceptable to say "restorer stubs are incompatible with
> stack-protector canaries: turn them off" -- there are plenty of places
> that are incompatible with canaries for good reason, and quite a lot of
> the glibc patch series has been identifying these and turning the stack-
> protector off for them -- but it is probably less acceptable to crash
> the kernel if they don't do that! So at least some extra armouring seems
> to be called for.

BTW Nick, in thinking through all of this, I want to strongly encourage
you to disable stack protector for all sigreturn stubs in the GLIBC tree.

The reason is that any change in the code generated is going to break
critical pieces of infrastructure.

For example, one of the ways in which gdb knows that it is unwinding
through a signal frame is that it parses the code at the program
counter for that frame and looks at the instruction sequence to see if
matches the signature for a sigreturn stub.

So a glibc with stack protector enabled for sigreturn stubs would break
backtracing in gdb.

The unwinder in libgcc does the same exact thing.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite Nick Alcock <nix@esperi.org.uk> - 2016-05-27 13:30 +0200
  [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite Nick Alcock <nix@esperi.org.uk> - 2016-05-27 15:20 +0200
    Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged  panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer,  courtesy of the glibc testsuite John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2016-05-27 15:40 +0200
      Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite Nick Alcock <nix@esperi.org.uk> - 2016-05-27 15:50 +0200
    Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged  panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer,  courtesy of the glibc testsuite David Miller <davem@davemloft.net> - 2016-05-27 21:40 +0200
      Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite Nick Alcock <nix@esperi.org.uk> - 2016-05-27 23:50 +0200
        Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged  panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer,  courtesy of the glibc testsuite David Miller <davem@davemloft.net> - 2016-05-28 01:00 +0200
          Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged  panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer,  courtesy of the glibc testsuite David Miller <davem@davemloft.net> - 2016-05-29 06:30 +0200
            Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged  panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer,  courtesy of the glibc testsuite Sam Ravnborg <sam@ravnborg.org> - 2016-05-29 19:40 +0200
              Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged  panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer,  courtesy of the glibc testsuite David Miller <davem@davemloft.net> - 2016-05-30 04:20 +0200
    Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged  panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer,  courtesy of the glibc testsuite David Miller <davem@davemloft.net> - 2016-05-29 08:10 +0200
      Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite Nix <nix@esperi.org.uk> - 2016-05-30 14:50 +0200

csiph-web