Date: Thu, 26 Nov 2015 09:54:25 +0100 From: Ingo Molnar <mingo@...nel.org> To: PaX Team <pageexec@...email.hu> Cc: 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>, Andy Lutomirski <luto@...capital.net>, 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@...r.kernel.org, Emese Revfy <re.emese@...il.com> Subject: Re: [PATCH 0/2] introduce post-init read-only memory * PaX Team <pageexec@...email.hu> wrote: > On 25 Nov 2015 at 10:13, Mathias Krause wrote: > > > I myself had some educating experience seeing my machine triple fault > > when resuming from a S3 sleep. The root cause was a variable that was > > annotated __read_only but that was (unnecessarily) modified during CPU > > bring-up phase. Debugging that kind of problems is sort of a PITA, you > > could imagine. ( Sidenote: I don't think a ro-faults typically result in triple faults, but yeah, even having a regular oops (followed by a hang or reboot) during such an undebuggable state of the system is a major PITA. ) > actually the kernel could silently recover from this given how the page fault > handler could easily determine that the fault address fell into the > data..read_only section and just silently undo the read-only property, log the > event to dmesg and retry the faulting access. So a safer method would be to decode the faulting instruction, to skip it by fixing up the return RIP and to log the event. It would be mostly equivalent to trying to write to ROM (which get ignored as well), so it's a recoverable (and debuggable) event. We have all the necessary code in place in the kprobes code, see arch/x86/lib/insn.c, it's a simplified x86 decoder that knows about instruction length (but not about semantics). Simple skipping plus setting arithmetic flags to init value should be enough I think: I don't think we use fancy instructions to write to ro variables, such as PUSH/POP with other side effects. If such instructions exist we could minimally extend the decoder to do those fixups as well - in addition to double checking that we skip simple instructions only with no side effects. Can you see any fragility in such a technique? Thanks, Ingo
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.