Date: Tue, 29 Mar 2016 17:14:45 -0600 From: Scotty Bauer <sbauer@....utah.edu> To: Linus Torvalds <torvalds@...ux-foundation.org>, Andy Lutomirski <luto@...capital.net> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, X86 ML <x86@...nel.org>, Andi Kleen <ak@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, wmealing@...hat.com Subject: Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies On 03/29/2016 04:34 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 4:38 PM, Andy Lutomirski <luto@...capital.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@...e0:/mnt/criu# criu restore -vvvv -o restore.log --shell-job root@...e0:/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_ bad frame in rt_sigreturn frame:000000000001e540 ip:7f561542cf20 sp:7ffe004ecfd8 orax:ffffffffffffffff in libc-2.19.so[7f561536c000+1bb0] root@...e0:/mnt/criu# echo 1 > /proc/sys/kernel/disable-srop-protection root@...e0:/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@...e0:/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?
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.