linux-kernel - Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17

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: <20060920163729.GA14961@Krystal>
Date:	Wed, 20 Sep 2006 12:37:29 -0400
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Karim Yaghmour <karim@...rsys.com>, linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Douglas Niehaus <niehaus@...s.ku.edu>,
	Tom Zanussi <zanussi@...ibm.com>,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	systemtap@...rces.redhat.com, ltt-dev@...fik.org
Subject: Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17

* Frank Ch. Eigler (fche@...hat.com) wrote:
> While varargs simplify some things, it sacrifices type-safety, in that
> a handler function would have to be varargs too.  For the systemtap
> marker prototype, parametrized variants use scores of (automatically
> generated) macros, with different arity/type permutations, each
> self-describing and type-safe.
> 
The format string could be used to provide some kind of type safety : the
compiler will check that arguments match the format string provided. From there,
a simple script can parse the format string and generate a function prototype
accordingly. Correct me if I am wrong, but I think that if the called function
has the exact same parameter layout as the varargs caller stack, the function
call should work (without the called function having a variable arguments list).

> Regarding a marker variant that would require kprobes (inserting a
> labelled NOP or few), it may be an appropriate choice where dormant
> marker overhead must be minimal and robust parameter passing is less
> important.
> 

I even came with the following idea :

Instead of using a test + conditional predicted branch, we could jump to an
address locate just after the probe.

  jmp to over_symbol address
call_symbol
  call function pointer
over_symbol

This way, we could have portable :
- direct inconditional jump to an address following the marked site when
  disabled
- Enable stack setup and function call by setting the function pointer and
  changing the jmp target to be "call_symbol"
- Enable "direct jump to arbitrary assembly" by setting the jump target to
  arbitrary code, where this code can end by jumping to over_symbol.

The generated binary on x86 looks like :

  10:   a1 24 00 00 00          mov    0x24,%eax
  15:   ff e0                   jmp    *%eax
  17:   c7 44 24 04 01 00 00    movl   $0x1,0x4(%esp)
  1e:   00 
  1f:   c7 04 24 00 00 00 00    movl   $0x0,(%esp)
  26:   ff 15 1c 00 00 00       call   *0x1c

With those symbols :

f8875c08 b __mark_subsys_mark1_call     [test_mark]  (function pointer)
f8875620 d __mark_subsys_mark1_jump_call        [test_mark]
f8875624 d __mark_subsys_mark1_jump_over        [test_mark]

The macro doing that :

#define MARK_CALL(name, format, args...) \
        do {\
                __label__ call_label, over_label; \
                static void *__mark_##name##_jump_over \
                        asm ("__mark_"#name"_jump_over") = \
                        &&over_label; \
                static void *__mark_##name##_jump_call \
                                asm ("__mark_"#name"_jump_call") \
                                __attribute__((unused)) =  \
                                &&call_label; \
                static void (*__mark_##name##_call)(const char *fmt, ...) \
                        asm ("__mark_"#name"_call") = __mark_empty_function; \
                goto *__mark_##name##_jump_over; \
call_label: \
                (void) (__mark_##name##_call(format, ## args)); \
over_label: \
                do {} while(0); \
        } while(0)

A problem I saw in your approach was that there was no way to remove the
function pointer without taking the risk to break everything.

The solution I came up with is to set the function to an empty
__mark_empty_function when disabled, and set another function pointer to enable
it.

Any thoughts ?

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)