linux-kernel - Re: [PATCH -tip 0/6 V4] tracing: kprobe-based event tracer

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: <49D61489.9020406@redhat.com>
Date:	Fri, 03 Apr 2009 09:52:09 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Vegard Nossum <vegard.nossum@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>, Avi Kivity <avi@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Jim Keniston <jkenisto@...ibm.com>, kvm@...r.kernel.org,
	systemtap-ml <systemtap@...rces.redhat.com>,
	LKML <linux-kernel@...r.kernel.org>, Pekka Paalanen <pq@....fi>
Subject: Re: [PATCH -tip 0/6 V4] tracing: kprobe-based event tracer

Vegard Nossum wrote:
> 2009/4/3 Ingo Molnar <mingo@...e.hu>:
>> * Avi Kivity <avi@...hat.com> wrote:
>>
>>> Ingo Molnar wrote:
>>>>> kvm has three requirements not needed by kprobes:
>>>>> - it wants to execute instructions, not just decode them, including
>>>>>   generating faults where appropriate
>>>>> - it is performance critical
>>>>> - it needs to support 16-bit, 32-bit, and 64-bit instructions simultaneously
>>>>>
>>>>> If an arch/x86/ decoder/emulator gives me these I'll gladly switch
>>>>> to it.  x86_emulate.c is high on my list of most disliked code.
>>>>>
>>>> Well, this has to be driven from the KVM side as the kprobes use
>>>> will only be for decoding so if it's modified from the kprobes
>>>> side the KVM-only functionality might regress.
>>>>
>>>> So ... we can do the library decoder for kprobes purposes, and
>>>> someone versed in the KVM emulator can then combine the two.
>>> Problem is, anyone versed in the kvm emulator will want to run as
>>> far away from this work as possible.
>> Are you suggesting that the KVM emulator should never have been
>> merged in the first place? ;-)
>>
>> Anyway, we'll make sure the kprobes/library decoder is as clean as
>> possible - so it ought to be hackable and extensible without the
>> risk of permanent brain damage. Mmiotrace and kmemcheck has decoding
>> smarts too, and i think the sw-breakpoint injection code of KGDB
>> could use it as well - so there's broader utility in all this.
> 
> (Sorry in advance for jumping in -- my post may be irrelevant)

Thank you for clarify your needs :-)

> For the record, kmemcheck requirements for an instruction decoder are these:
> 
> For any instruction with memory operands, we need to know which are
> the operands (so for movl %eax, (%ebx) we need to combine the
> instruction with a struct pt_regs to get the actual address
> dereferenced, i.e. the contents of %ebx), and their sizes (for movzbl,
> the source operand is 8 bits, destination operand is 32 bits). For
> things like movsb, we need to be able to get both %esi and %edi.

New decoder can give you the value of mod/rm(insn.modrm), operand size
(insn.opnd_bytes), and immediate size (insn.immediate.nbytes)
To get which register is used, you can decode modrm with MODRM_*()
macros.

> mmiotrace additionally needs to know what the actual values
> read/written were, for instructions that read/write to memory (again,
> combined with a struct pt_regs).

The decoder doesn't use any locks/shared memory, so you can
use it in interrupt context, with pt_regs.

> Maybe this doesn't really say much, since this is what a generic
> instruction decoder would be able to do anyway. But kmemcheck and
> mmiotrace both have very special-purpose decoders. I don't really know
> what other decoders look like, but what I would wish for is this: Some
> macros for iterating the operands, where each operand has a type (e.g.
> input (for reads), output (for writes), target (for jumps), immediate
> address, immediate value, etc.), a size (in bits), and a way to
> evaluate the operand. So eval(op, regs) for op=%eax, it will return
> regs->eax; for op=4(%eax), it will return regs->eax + 4; for op=4 it
> will return 4, etc.

Hmm, it's an interesting idea. I think operand classifying can be done by
evaluating opcode and mod/rm.

> Both kmemcheck and mmiotrace could gain SMP support with instruction
> emulation, though it is strictly not necessary. In that case, though,
> we would not want to emulate fault handling, etc. (i.e. the fault
> should always be generated by the CPU itself).
> 
> Please do put me on Cc for future discussions, though.

Of course, thank you!

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

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