[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxH+Gy4U8WbGWXh+ybrvng8tw1=2CrjPnJSju3+c5XpbA@mail.gmail.com>
Date: Fri, 27 Nov 2015 10:00:36 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: 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>, Kees Cook <keescook@...omium.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 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
- 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
- have an option to disable the RO data logic.
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
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.
