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]

Date:	Fri, 4 Apr 2008 16:18:53 +0300
From:	Pekka Paalanen <pq@....fi>
To:	"Vegard Nossum" <vegard.nossum@...il.com>
Cc:	avi@...ranet.com, linux-kernel@...r.kernel.org,
	"Ingo Molnar" <mingo@...e.hu>,
	"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
Subject: Re: mmiotrace bug: recursive probe hit

On Thu, 3 Apr 2008 23:40:28 +0200
"Vegard Nossum" <vegard.nossum@...il.com> wrote:

> On Thu, Apr 3, 2008 at 11:07 PM, Pekka Paalanen <pq@....fi> wrote:
> > ...

> We do indeed limit maxcpus to 1 at run-time if the kernel is compiled
> with CONFIG_SMP. kmemcheck is a debugging facility, and as such,
> actual multiprocessor support is not critical for the purpose of
> kmemcheck, in my opinion. Doesn't the same hold for mmiotrace?

Actually, I think kmemcheck should support SMP even more than mmiotrace.
Mmiotrace is just a reverse engineering tool for hardware drivers, but
kmemcheck as a debugging tool could be valuable specifically on SMP,
think about racing CPUs using and initializing memory. Dropping to UP
might hide those problems.

> >  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.
> 
> I think that would be extremely difficult to do. I am personally
> trying to stay as far away from opcode decoding (and recoding!
> *shudder*) as possible. I do the minimal decoding for operand sizes,
> etc, which I think you do as well in mmiotrace.

To be honest, I don't know how easy or difficult it is. If there was a
general decoding facility, it shouldn't be that hard to use, if someone
else makes the facility for us ;-)
Could all relevant instructions be represented as three-address-code or
in some other simple form?
This seems to require some experimenting with code.

-- 
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/