linux-kernel - Re: [PATCH] Linux Kernel Markers

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: <451178B0.9030205@opersys.com>
Date:	Wed, 20 Sep 2006 13:21:52 -0400
From:	Karim Yaghmour <karim@...rsys.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC:	Martin Bligh <mbligh@...gle.com>, prasanna@...ibm.com,
	Andrew Morton <akpm@...l.org>,
	"Frank Ch. Eigler" <fche@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Paul Mundt <lethal@...ux-sh.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>, ltt-dev@...fik.org,
	systemtap@...rces.redhat.com, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Kernel Markers

Masami Hiramatsu wrote:
> This method is very similar to the djprobe.
> And I had gotten the same idea to support preemptive kernel.
...
> This means the below code, doesn't this?
> ---
> 	jmp 1f /* short jump consumes 2 bytes */
> 	nop
> 	nop
> 	nop
> 1:

Actually this is slightly different (and requires more support
on behalf of the underlying mechanism then what I was suggesting.)
Basically, as was discussed elsewhere, there is some complex
mechanisms required for taking care of the case where you got
an interrupt at, say, the second or third nop. With the
mechanism I'm suggesting (replacing a 5 byte jmp with a 5 byte
jmp), the underlying mechanics do not require having to take
care of the above-mentioned case.

>      - Serialize all processor's cache by using IPI and cpuid.

Yes.

> I think the djprobe can provide most of functionalities which
> your idea requires.
> I'll update the djprobe against for 2.6.17 or later as soon as
> possible. Would you try to use it?

Basically I'm trying to come up with a mechanism that will be
relatively trivial to implement on any architecture. My
understanding is that kprobes/djprobes combo do not necessarily
fit this description. Of course, that's not a justification for
not trying to get it to work, but my understanding is that
Martin's proposal, if it were implemented, would have a number
of advantages over just having kprobes/djprobes.

Though, in fact, djprobes can be used on the x86 (since it
already works on that) for doing exactly what I'm looking
for: replacing a 5 byte jmp with a 5 byte jmp. My understanding
is that djprobes doesn't need any special intelligence (even
on preemptable kernels) here since it shouldn't need to worry
about an IP back anywhere inside a series of nops. IOW, we
should be able to do what Martin suggests fairly easily (if
we agree on a 5-byte "null" jump at the entry of functions
of interest). Right?

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