On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: >> >> * Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
