linux-kernel - Re: mmiotrace bug: recursive probe hit

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: <20080404000701.70bbc1a4@daedalus.pq.iki.fi>
Date:	Fri, 4 Apr 2008 00:07:01 +0300
From:	Pekka Paalanen <pq@....fi>
To:	avi@...ranet.com, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Pavel Roskin <proski@....org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	penberg@...helsinki.fi, vegard.nossum@...il.com
Subject: Re: mmiotrace bug: recursive probe hit

On Sun, 30 Mar 2008 20:26:08 +0300
Pekka Paalanen <pq@....fi> wrote:

> 
> C) Vegard mentioned something about per-cpu page tables for kmemcheck.
> This would be the ultimate solution, because it would solve two problems:
> - recursive probe hits
> - missed events due to another cpu disarming the page for single stepping
> Would it be possible to have a single temporary per-cpu pte?
> 
> I understood kmemcheck has similar issues. Of course, one could force the
> system down to a single running CPU, but that feels nasty.

One more idea:

D) Emulate the faulting instruction.
In __ioremap(), do the mapping, but steal it for mmiotrace's personal use,
and return a bogus mapping that is identifiable in #pf handler. When
something accesses the bogus mapping, emulate and step over the faulting
instruction using the stolen IO memory mapping. This would get rid of
the debug trap and single stepping, and also remove the need to disarm
the mmio page, which means tracing would work reliably on SMP without
any page table kludges. This would also remove the yet another instruction
decoding code that mmiotrace has.

The catch is the instruction emulation. I see KVM has some emulation code,
but I cannot understand it without a deep study that would take me weeks.
Is that general enough to be used, or could it be generalized?
Mmiotrace, apart from executing the instruction with a modified address,
would need to extract the type of IO memory access, width and the data
read/written. And since it is dealing with IO memory, the emulation
should be very careful to access the hardware exactly like the original
instruction would have.

Maybe also kmemcheck could use this approach, since the current approach
is very much like in mmiotrace: #pf, show page, single step, #db trap,
hide page.

Are there other x86(_64) instruction emulation facilities in the kernel
I might use?

Or, if the emulation cannot be used, what would it take to make at least
instruction decoding general enough so that mmiotrace could use that instead
of its own decoding?

I fear modifying KVM emulation code is a too heavy job for me personally.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/