Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754754AbbK0UDo (ORCPT ); Fri, 27 Nov 2015 15:03:44 -0500 Received: from mail-ig0-f169.google.com ([209.85.213.169]:35743 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754004AbbK0UDm (ORCPT ); Fri, 27 Nov 2015 15:03:42 -0500 MIME-Version: 1.0 In-Reply-To: References: <1448401114-24650-1-git-send-email-keescook@chromium.org> <565595F5.32536.DB9FE75@pageexec.freemail.hu> <20151126085425.GA29848@gmail.com> <20151127075959.GA24991@gmail.com> Date: Fri, 27 Nov 2015 12:03:40 -0800 X-Google-Sender-Auth: -PBG-MbfC689ug4upQpd4Q8ozYg Message-ID: Subject: Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory From: Kees Cook To: Linus Torvalds Cc: Ingo Molnar , Andy Lutomirski , PaX Team , "kernel-hardening@lists.openwall.com" , Mathias Krause , "linux-kernel@vger.kernel.org" , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , x86-ml , Arnd Bergmann , Michael Ellerman , linux-arch , Emese Revfy Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3021 Lines: 74 On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar wrote: >> >> * Andy Lutomirski 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/