Date: Fri, 27 Nov 2015 12:03:40 -0800 From: Kees Cook <keescook@...omium.org> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...capital.net>, PaX Team <pageexec@...email.hu>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Mathias Krause <minipli@...glemail.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, x86-ml <x86@...nel.org>, Arnd Bergmann <arnd@...db.de>, Michael Ellerman <mpe@...erman.id.au>, linux-arch <linux-arch@...r.kernel.org>, Emese Revfy <re.emese@...il.com> Subject: Re: [PATCH 0/2] introduce post-init read-only memory On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar <mingo@...nel.org> wrote: >> >> * Andy Lutomirski <luto@...capital.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
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.