lkml.org 
[lkml]   [2008]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] Tracepoint proposal
    From
    Date
    "Takashi Nishiie" <t-nishiie@np.css.fujitsu.com> writes:

    > [...]
    > Each kernel sub-system seems to have its own way of dealing with
    > debugging statements. Some of these methods include 'dprintk',
    > 'pr_debug', 'dev_debug', 'DEBUGP'. I think that these functions are
    > the tracepoints that has been availably mounted without setting up
    > the tool set of the outside. I think whether mounting that unites
    > these functions can be done if kernel marker and tracepoint are used.

    There are efforts underway to collect these various debug methods into
    a single run-time-dynamic stream, which may even turn out to connect
    to markers.

    > By the way, isn't there problem on security? What kprobe, jprobe,
    > and kernel marker, etc. offer looks like what the framework of Linux
    > Security Module had offered before. Gotten kprobe, jprobe, and
    > kernel marker, etc. should not be exported to the userland for
    > security because it becomes the hotbed of rootkits.

    These are all kernel-side facilities with no direct connection to
    user-land.

    > Users such as kprobe, jprobe, and kernel marker should not be
    > Loadable Kernel Module. [...]

    That would defeat their usefulness. Remember, kernel modules run with
    no hardware-level restrictions at all, so if an adversary managed to
    load up some kernel malware module, the game is over, whether or not
    they use kprobes.

    - FChE


    \
     
     \ /
      Last update: 2008-06-24 14:01    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean