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: <20080716105644.GB5413@redhat.com>
Date:	Wed, 16 Jul 2008 06:56:44 -0400
From:	"Frank Ch. Eigler" <fche@...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)

Hi -

On Tue, Jul 15, 2008 at 09:06:23PM -0500, James Bottomley wrote:
> [...]
> > Please choose your words more carefully.  We don't "subvert" anything,
> > where one would mean sneaking around some sort of protection.
> 
> Actually, I did and you do.  One of the OED's definition of subvert is
> "to undermine or overturn a condition or order of things, a principle or
> a law etc."  In this particular case, this:
> 
> commit 3a872d89baae821a0f6e2c1055d4b47650661137
> Author: Ananth N Mavinakayanahalli <ananth@...ibm.com>
> Date:   Mon Oct 2 02:17:30 2006 -0700
>     [PATCH] Kprobes: Make kprobe modules more portable
>
> Which provided a portable input to kprobes (the symbol_name/offset one)
> and revoked the global accessibility of the kallsyms_lookup_name().

That patch served two purposes: a helpful utility for other kprobes
users, and it enabling what LKML deemed more important - unexporting
kallsyms*.


> It's actually worse than this, though.  The kernel API isn't fixed in
> stone, it evolves usually by trying to make problematic use cases
> better.  By refusing to consider using the replacement API [...]

Your lecture is based upon a misundertanding ...


> [...]
> It emits a single probe and produces this in the module build:
> -rw-r--r-- 1 root root  17996 2008-07-15 20:45 stap_2154.c
> About 600 lines.
> However, it also needs this for the symbol table:
> -rw-r--r-- 1 root root 446137 2008-07-15 20:45 stap-symbols.h

... that this is somehow connected to the kprobe api issue.

IT IS NOT.

We do not use those symbol tables for kprobe placement purposes.
(This part is partially a prototype for user-space parts, and the
sizes will not stay large.)

The way we set up kprobes now could be trivially converted to
"_stext"+offset.  Would that alone allay your concerns?


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ