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-next>] [day] [month] [year] [list]
Date:	Tue, 15 Jul 2008 15:41:31 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
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 <James.Bottomley@...senPartnership.com> writes:

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

It is a compromise of conflicting requirements. 

> This is highly undesirable because it represents a subversion of the
> kernel API to gain access to unexported symbols.

Please elaborate.  Does the translator or its runtime use unexported
symbols?  (That would arouse the question about why.)

Or are you talking about being able to *probe* unexported functions or
access unexported data?  That would be a deliberate feature.

> At least for kprobes, the correct way to do this is to specify the
> probe point by symbol and offset.

But there won't be just kprobes.  Much of this code was built with
anticipation of user-space probing, and there the kernel won't have a
similar mechanism.  Similarly, the code is written to work with old
kernels too - ones that predate the symbol+offset kprobe API.

Unless someone is about to rip out pure address-based kprobes, I see
no reason to complicate the code.


- 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