Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1366781
| 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:20 +0200 |
| Message-ID | <rib5x-4TO-23@gated-at.bofh.it> (permalink) |
| References | <ri7XX-2vZ-3@gated-at.bofh.it> <ri9n3-3BH-1@gated-at.bofh.it> <ri9wJ-3Fl-3@gated-at.bofh.it> <ri9wJ-3Fl-1@gated-at.bofh.it> <riasN-4m1-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 03/29/2016 04:34 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 4:38 PM, Andy Lutomirski <luto@amacapital.net> wrote: >> >> Then there's an unanswered question: is this patch acceptable given >> that it's an ABI break? Security fixes are sometimes an exception to >> the "no ABI breaks" rule, but it's by no means an automatic exception. > > So there isn't any "no ABI break" rule - there is only a "does it > break real applications" rule. > > (This can also be re-stated as: "Talk is cheap", aka "reality trumps > documentation". > > Documentation is meaningless if it doesn't match reality, and what we > actually *do* is what matters. > > So the ABI isn't about some theoretical interface documentation, the > ABI is about what people use and have tested. > > On the one hand, that means that that our ABI is _stricter_ than any > documentatiuon, and that "but we can make this change that breaks app > XYZ, because XYZ is depending on undocumented behavior" is not an > acceptable excuse. > > But on the other hand it *also* means that since the ABI is about real > programs, not theoretical issues, we can also change things as long as > we don't actually break anything that people can notice and depend > on). > > And while *acute* security holes will be fixed regardless of ABI > issues, something like this that is only hardening rather than fixing > a particular security hole, really needs to not break any > applications. > > Because if it does break anything, it needs to be turned off by > default. That's a hard rule. And since that would be largely defeating > the whole point o fthe series, I think we really need to have made > sure nothing breaks before a patch series like this can be accepted. > > That said, if this is done right, I don't think it will break > anything. CRIU may indeed be a special case, but CRIU isn't really a > normal application, and the CRIU people may need to turn this off > explicitly, if it does break. > > But yes, dosemu needs to be tested, and needs to just continue > working. But does dosemu actually create a signal stack, as opposed to > just playing with one that has been created for it? I thought it was > just the latter case, which should be ok even with a magic cookie in > there. > > Linus > For what it's worth this series is breaking CRIU, I just tested: root@node0:/mnt/criu# criu restore -vvvv -o restore.log --shell-job root@node0:/mnt/criu# tail -3 /var/log/syslog Mar 29 17:12:08 localhost kernel: [ 3554.625535] Possible exploit attempt or buggy program! Mar 29 17:12:08 localhost kernel: [ 3554.625535] If you believe this is an error you can disable SROP Protection by #echo 1 > /proc/sys/kernel/disable-srop-protection Mar 29 17:12:08 localhost kernel: [ 3554.625545] test_[25305] bad frame in rt_sigreturn frame:000000000001e540 ip:7f561542cf20 sp:7ffe004ecfd8 orax:ffffffffffffffff in libc-2.19.so[7f561536c000+1bb0] root@node0:/mnt/criu# echo 1 > /proc/sys/kernel/disable-srop-protection root@node0:/mnt/criu# criu restore -vvvv -o restore.log --shell-job slept for one second slept for one second slept for one second slept for one second root@node0:/mnt/criu# I'm working on getting dosemu up and running-- are there any other applications off the top of your head that I should be testing with?
Back to linux.kernel | Previous | Next — Previous in thread | Next 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