linux-kernel - Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol

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]

Date:	Wed, 16 Jul 2008 18:40:45 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	systemtap@...rceware.org
Subject: Re: [RFC] systemtap: begin the process of using proper kernel APIs
 (part1: use kprobe symbol_name/offset instead of address)

James Bottomley wrote:
> One of the big nasties of systemtap is the way it tries to embed
> virtually the entirety of the kernel symbol table in the probe modules
> it constructs.  This is highly undesirable because it represents a
> subversion of the kernel API to gain access to unexported symbols.  At
> least for kprobes, the correct way to do this is to specify the probe
> point by symbol and offset.
> 
> This patch converts systemtap to use the correct kprobe
> symbol_name/offset pair to identify the probe location.

Hi James,

I think your suggestion is a good step. Of course, it might
have to solve some issues.

Unfortunately, current kprobe's symbol_name interface is not
so clever. For example, if you specify a static function
which is defined at several places in the kernel(ex. do_open),
it always pick up the first one in kallsyms, even if systemtap
can find all of those functions.
(you can find many duplicated symbols in /proc/kallsyms)

So, we might better improve kallsyms to treat this case
and find what is a better way to specify symbols and addresses.

> 
> This only represents a baby step:  after this is done, there are at
> least three other consumers of the systemtap module relocation
> machinery:
> 
>      1. unwind information.  I think the consumers of this can be
>         converted to use the arch specific unwinders that already exist
>         within the kernel
>      2. systemtap specific functions that use kernel internals.  This
>         was things like get_cycles() but I think they all now use a
>         sanctioned API ... need to check

Sure, those functions must be well isolated from other parts of kernel.
unfortunately, relayfs is not enough isolated. see below;
http://sources.redhat.com/bugzilla/show_bug.cgi?id=6487

>      3. Access to unexported global variables used by the probes.  This
>         one is a bit tricky; the dwarf gives a probe the ability to
>         access any variable available from the probed stack frame,
>         including all globals.  We could just make the globals off
>         limits, but that weakens the value of the debugger.
>         Alternatively, we could expand the kprobe API to allow probes
>         access to named global variables (tricky to get right without
>         effectively giving general symbol access).  Thoughts?

Could we provide a separated GPL'd interface to access named global
symbols which is based on kallsyms?

Thank you,

> If you're going to try this out, you currently need to specify --kelf on
> the command line to tell systemtap to use the kernel elf to derive
> symbol names and offsets (it will just segfault without this ATM).
> 
> James

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