linux-kernel - Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151126085425.GA29848@gmail.com>
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: [kernel-hardening] [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/