Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1366793
| From | Scotty Bauer <sbauer@eng.utah.edu> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies |
| Date | 2016-03-30 01:40 +0200 |
| Message-ID | <riboS-53f-21@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> <ribfc-4ZF-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 03/29/2016 05:25 PM, Linus Torvalds wrote: > 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 > Alright I'll test Wine/Mono, Dosemu, some random languages/debuggers see if there is anything that breaks. Thanks.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll 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