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  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 <>
To:	"Vegard Nossum" <>
	"Ingo Molnar" <>,
	"Christoph Hellwig" <>,
	"Arjan van de Ven" <>,
	"Pavel Roskin" <>,
	"Steven Rostedt" <>,
	"Peter Zijlstra" <>,
Subject: Re: mmiotrace bug: recursive probe hit

On Thu, 3 Apr 2008 23:40:28 +0200
"Vegard Nossum" <> wrote:

> On Thu, Apr 3, 2008 at 11:07 PM, Pekka Paalanen <> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists