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


Groups > linux.kernel > #1366787

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

From Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups linux.kernel
Subject Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies
Date 2016-03-30 01:30 +0200
Message-ID <ribfc-4ZF-5@gated-at.bofh.it> (permalink)
References <ri7XX-2vZ-3@gated-at.bofh.it> <riaMa-4u5-15@gated-at.bofh.it> <rib5w-4TO-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Mar 29, 2016 at 6:11 PM, Scotty Bauer <sbauer@eng.utah.edu> wrote:
>
> Yeah I had toyed with using hashes, I used hash_64 not md5 which is like 14
> extra instructions or something.

That sounds fine. Anything that requires enough code to undo that it
kind of defeats the purpose of a SROP should be enough. It's not about
encryption, I'd just think that if you can force the buffer overflow
while already in a signal handler, you'd want something that is at
least *slightly* harder to defeat than a single "xor" instruction.

> It's not hard to implement So I can try it. When you say an extra hardening
> mode do you mean hide it behind a sysctl or some sort of compile time CONFIG?

Since there already is a sysctl, I'd just assume that.

The important part is that the *default* value for that sysctl can't
break real applications. I don't really count CRIU as a real app, if
only because once you start doing checkpoint-restore you are going to
do some amount of system maintenance anyway, so somebody doing CRIU is
kind of expected to have a certain amount of system expertise, I would
say.

But dosemu - or Wine - is very much something that "normal people" run
- people who we do *not* expect to have to know about new sysctl's
etc. They already have one (mmap at zero), but that is very directly
related to what vm86 mode and Wine does, and people have had time to
learn about it. Let's not add another.

So testing dosemu and wine would be good. I wonder what else has shown
issues with signal stack layout changes. Debuggers and some JIT
engines, I suspect.

              Linus

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


Thread

[PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Scott Bauer <sbauer@eng.utah.edu> - 2016-03-29 22:00 +0200
  [PATCH v4 1/4] SROP Mitigation: Architecture independent code for signal cookies Scott Bauer <sbauer@eng.utah.edu> - 2016-03-29 22:00 +0200
    Re: [PATCH v4 1/4] SROP Mitigation: Architecture independent code for  signal cookies Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-30 01:10 +0200
    Re: [PATCH v4 1/4] SROP Mitigation: Architecture independent code for signal cookies ebiederm@xmission.com (Eric W. Biederman) - 2016-03-31 22:40 +0200
      Re: [PATCH v4 1/4] SROP Mitigation: Architecture independent code for  signal cookies Linus Torvalds <torvalds@linux-foundation.org> - 2016-04-01 00:10 +0200
        Re: [PATCH v4 1/4] SROP Mitigation: Architecture independent code for signal cookies ebiederm@xmission.com (Eric W. Biederman) - 2016-04-01 00:30 +0200
  Re: [PATCH v4 3/4] Sysctl: SROP Mitigation: Add Sysctl argument to  disable SROP. Andi Kleen <ak@linux.intel.com> - 2016-03-29 22:00 +0200
    Re: [PATCH v4 3/4] Sysctl: SROP Mitigation: Add Sysctl argument to  disable SROP. Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-29 22:50 +0200
      Re: [PATCH v4 3/4] Sysctl: SROP Mitigation: Add Sysctl argument to  disable SROP. Andi Kleen <ak@linux.intel.com> - 2016-03-29 23:00 +0200
  [PATCH v4 3/4] Sysctl: SROP Mitigation: Add Sysctl argument to disable SROP. Scott Bauer <sbauer@eng.utah.edu> - 2016-03-29 22:00 +0200
  [PATCH v4 2/4] x86: SROP Mitigation: Implement Signal Cookies Scott Bauer <sbauer@eng.utah.edu> - 2016-03-29 22:00 +0200
  Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Andy Lutomirski <luto@amacapital.net> - 2016-03-29 23:30 +0200
    Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Andy Lutomirski <luto@amacapital.net> - 2016-03-29 23:40 +0200
      Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-30 00:40 +0200
        Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-30 01:20 +0200
          Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies ebiederm@xmission.com (Eric W. Biederman) - 2016-03-31 22:40 +0200
            Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Cyrill Gorcunov <gorcunov@gmail.com> - 2016-04-01 15:00 +0200
      Re: [kernel-hardening] Re: [PATCH v4 0/4] SROP Mitigation:  Sigreturn Cookies Daniel Micay <danielmicay@gmail.com> - 2016-03-30 01:00 +0200
    Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-29 23:40 +0200
  Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-30 01:00 +0200
    Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-30 01:00 +0200
    Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Andy Lutomirski <luto@amacapital.net> - 2016-03-30 01:10 +0200
    Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-30 01:20 +0200
      Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-30 01:30 +0200
        Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-30 01:40 +0200

csiph-web