From: Kees Cook <keescook@chromium.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@amacapital.net>, PaX Team <pageexec@freemail.hu>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Mathias Krause <minipli@googlemail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, x86-ml <x86@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Michael Ellerman <mpe@ellerman.id.au>, linux-arch <linux-arch@vger.kernel.org>, Emese Revfy <re.emese@gmail.com> Subject: Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Date: Fri, 27 Nov 2015 12:03:40 -0800 [thread overview] Message-ID: <CAGXu5j+mvknX69Kk1S8u54LR4T+KED8zZdkqQWA9KMrOvtVQtQ@mail.gmail.com> (raw) In-Reply-To: <CA+55aFxH+Gy4U8WbGWXh+ybrvng8tw1=2CrjPnJSju3+c5XpbA@mail.gmail.com> On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar <mingo@kernel.org> wrote: >> >> * Andy Lutomirski <luto@amacapital.net> wrote: >> >>> > Can you see any fragility in such a technique? >>> >>> After Linus shot down my rdmsr/rwmsr decoding patch, good luck... >> >> I think that case was entirely different, but I've Cc:-ed Linus to shoot my idea >> down if it's crap. > > Yeah, no, I hate it. I'm with the PaX team on this one - I think there > are three valid responses, and I think we might want to have a dynamic > config option (kernel command line or proc or whatever) to pick > between the two: > > - just oops and kill the machine, like for any other unhandled kernel > page fault. This is probably what you should have on a server This is how the v2 series works now. > - print a warning and a backtrace, and just mark the page read-write > so that the machine survives, but we get notified and can fix whatever > broken code This seems very easy to add. Should I basically reverse the effects of mark_rodata_ro(), or should I only make the new ro-after-init section as RW? (I think the former would be easier.) > - have an option to disable the RO data logic. I added this as "rodata=off" in the v2 series. > I think that second option is good for debugging. In some places, > oopses that kill things are just too hard to debug (ie it might be the > modesetting or early boot or whatever). > > In fact, I think we should _start_ with the second option - perhaps > just during the rc's - and then when we're pretty sure all the silly > bugs it finds (maybe none, who knows) are handled, we should go to the > first one. > > The third option would be purely for "user that cannot fix things > directly and has reported the problem can now turn off the distracting > warning". We should never default to it. > > Trying to actually *recover* any other way thanm by turning the area > read-write is just too damn fragile. You can't just skip over the > instruction that does the write - there are flags values etc that get > updated by read-modify-write instructions, but as PaX says, there nmay > also be subsequent logic that gets confused and actually introduces > even *more* problems downstream if the write is just discarded. > > So maybe we could have some kind of "mark it read-only again later" > thing that tries to make sure it doesn't stay writable for a long > time, but quite frankly, I don't think it's worth it. Once the write > has been done, and the warning has been emitted, there's likely very > little upside to then trying to close the barn doors after that horse > has bolted. > > Linus -Kees -- Kees Cook Chrome OS & Brillo Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@amacapital.net>, PaX Team <pageexec@freemail.hu>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Mathias Krause <minipli@googlemail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, x86-ml <x86@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Michael Ellerman <mpe@ellerman.id.au>, linux-arch <linux-arch@vger.kernel.org>, Emese Revfy <re.emese@gmail.com> Subject: Re: [PATCH 0/2] introduce post-init read-only memory Date: Fri, 27 Nov 2015 12:03:40 -0800 [thread overview] Message-ID: <CAGXu5j+mvknX69Kk1S8u54LR4T+KED8zZdkqQWA9KMrOvtVQtQ@mail.gmail.com> (raw) In-Reply-To: <CA+55aFxH+Gy4U8WbGWXh+ybrvng8tw1=2CrjPnJSju3+c5XpbA@mail.gmail.com> On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar <mingo@kernel.org> wrote: >> >> * Andy Lutomirski <luto@amacapital.net> wrote: >> >>> > Can you see any fragility in such a technique? >>> >>> After Linus shot down my rdmsr/rwmsr decoding patch, good luck... >> >> I think that case was entirely different, but I've Cc:-ed Linus to shoot my idea >> down if it's crap. > > Yeah, no, I hate it. I'm with the PaX team on this one - I think there > are three valid responses, and I think we might want to have a dynamic > config option (kernel command line or proc or whatever) to pick > between the two: > > - just oops and kill the machine, like for any other unhandled kernel > page fault. This is probably what you should have on a server This is how the v2 series works now. > - print a warning and a backtrace, and just mark the page read-write > so that the machine survives, but we get notified and can fix whatever > broken code This seems very easy to add. Should I basically reverse the effects of mark_rodata_ro(), or should I only make the new ro-after-init section as RW? (I think the former would be easier.) > - have an option to disable the RO data logic. I added this as "rodata=off" in the v2 series. > I think that second option is good for debugging. In some places, > oopses that kill things are just too hard to debug (ie it might be the > modesetting or early boot or whatever). > > In fact, I think we should _start_ with the second option - perhaps > just during the rc's - and then when we're pretty sure all the silly > bugs it finds (maybe none, who knows) are handled, we should go to the > first one. > > The third option would be purely for "user that cannot fix things > directly and has reported the problem can now turn off the distracting > warning". We should never default to it. > > Trying to actually *recover* any other way thanm by turning the area > read-write is just too damn fragile. You can't just skip over the > instruction that does the write - there are flags values etc that get > updated by read-modify-write instructions, but as PaX says, there nmay > also be subsequent logic that gets confused and actually introduces > even *more* problems downstream if the write is just discarded. > > So maybe we could have some kind of "mark it read-only again later" > thing that tries to make sure it doesn't stay writable for a long > time, but quite frankly, I don't think it's worth it. Once the write > has been done, and the warning has been emitted, there's likely very > little upside to then trying to close the barn doors after that horse > has bolted. > > Linus -Kees -- Kees Cook Chrome OS & Brillo Security
next prev parent reply other threads:[~2015-11-27 20:03 UTC|newest] Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-24 21:38 [PATCH 0/2] introduce post-init read-only memory Kees Cook 2015-11-24 21:38 ` [kernel-hardening] " Kees Cook 2015-11-24 21:38 ` [PATCH 1/2] x86: " Kees Cook 2015-11-24 21:38 ` [kernel-hardening] " Kees Cook 2015-11-25 0:34 ` Andy Lutomirski 2015-11-25 0:34 ` [kernel-hardening] " Andy Lutomirski 2015-11-25 0:34 ` Andy Lutomirski 2015-11-25 0:44 ` Kees Cook 2015-11-25 0:44 ` [kernel-hardening] " Kees Cook 2015-11-25 0:44 ` Kees Cook 2015-11-25 0:54 ` [kernel-hardening] " Michael Ellerman 2015-11-25 15:03 ` Kees Cook 2015-11-25 15:03 ` Kees Cook 2015-11-25 23:05 ` Michael Ellerman 2015-11-25 23:32 ` Kees Cook 2015-11-25 23:32 ` Kees Cook 2015-11-25 23:32 ` Kees Cook 2015-11-24 21:38 ` [PATCH 2/2] x86, vdso: mark vDSO read-only after init Kees Cook 2015-11-24 21:38 ` [kernel-hardening] " Kees Cook 2015-11-25 9:13 ` [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Mathias Krause 2015-11-25 9:13 ` Mathias Krause 2015-11-25 10:06 ` [kernel-hardening] " Clemens Ladisch 2015-11-25 11:14 ` PaX Team 2015-11-25 11:14 ` PaX Team 2015-11-26 15:23 ` [kernel-hardening] " Daniel Micay 2015-11-25 11:05 ` PaX Team 2015-11-25 11:05 ` PaX Team 2015-11-26 8:54 ` [kernel-hardening] " Ingo Molnar 2015-11-26 9:57 ` PaX Team 2015-11-26 9:57 ` PaX Team 2015-11-26 10:42 ` [kernel-hardening] " Ingo Molnar 2015-11-26 12:14 ` PaX Team 2015-11-26 12:14 ` PaX Team 2015-11-27 8:05 ` [kernel-hardening] " Ingo Molnar 2015-11-27 8:05 ` Ingo Molnar 2015-11-27 15:29 ` [kernel-hardening] " PaX Team 2015-11-27 15:29 ` PaX Team 2015-11-27 16:30 ` [kernel-hardening] " Andy Lutomirski 2015-11-27 16:30 ` Andy Lutomirski 2015-11-29 8:08 ` Ingo Molnar 2015-11-29 11:15 ` PaX Team 2015-11-29 11:15 ` PaX Team 2015-11-29 15:39 ` [kernel-hardening] " Ingo Molnar 2015-11-29 18:05 ` Mathias Krause 2015-11-29 18:05 ` Mathias Krause 2015-11-30 8:01 ` [kernel-hardening] " Ingo Molnar 2015-11-30 8:01 ` Ingo Molnar 2015-11-26 16:11 ` [kernel-hardening] " Andy Lutomirski 2015-11-26 16:11 ` Andy Lutomirski 2015-11-26 16:11 ` Andy Lutomirski 2015-11-27 7:59 ` [kernel-hardening] " Ingo Molnar 2015-11-27 7:59 ` Ingo Molnar 2015-11-27 7:59 ` Ingo Molnar 2015-11-27 18:00 ` [kernel-hardening] " Linus Torvalds 2015-11-27 18:00 ` Linus Torvalds 2015-11-27 18:03 ` Linus Torvalds 2015-11-27 18:03 ` Linus Torvalds 2015-11-27 18:03 ` Linus Torvalds 2015-11-27 20:03 ` Kees Cook [this message] 2015-11-27 20:03 ` [kernel-hardening] " Kees Cook 2015-11-27 20:03 ` Kees Cook 2015-11-27 20:09 ` [kernel-hardening] " Andy Lutomirski 2015-11-27 20:09 ` Andy Lutomirski 2015-11-29 8:05 ` Ingo Molnar 2015-11-29 8:05 ` Ingo Molnar 2015-11-30 21:14 ` H. Peter Anvin 2015-11-30 21:14 ` H. Peter Anvin 2015-11-30 21:14 ` H. Peter Anvin 2015-11-30 21:33 ` [kernel-hardening] " Kees Cook 2015-11-30 21:33 ` Kees Cook 2015-11-30 21:38 ` Andy Lutomirski 2015-11-30 21:38 ` Andy Lutomirski 2015-11-30 21:43 ` H. Peter Anvin 2015-11-30 21:43 ` H. Peter Anvin 2015-11-30 21:43 ` H. Peter Anvin 2015-11-25 17:26 ` [kernel-hardening] " Kees Cook 2015-11-25 17:26 ` Kees Cook 2015-11-25 17:26 ` Kees Cook 2015-11-25 17:31 ` [kernel-hardening] " H. Peter Anvin 2015-11-25 17:31 ` H. Peter Anvin 2015-11-25 18:54 ` [kernel-hardening] " Kees Cook 2015-11-25 18:54 ` Kees Cook 2015-11-25 19:06 ` H. Peter Anvin 2015-11-25 19:06 ` H. Peter Anvin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGXu5j+mvknX69Kk1S8u54LR4T+KED8zZdkqQWA9KMrOvtVQtQ@mail.gmail.com \ --to=keescook@chromium.org \ --cc=arnd@arndb.de \ --cc=hpa@zytor.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=minipli@googlemail.com \ --cc=mpe@ellerman.id.au \ --cc=pageexec@freemail.hu \ --cc=re.emese@gmail.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.