linux-kernel - Re: [RFC] fix kallsyms to allow discrimination of local symbols

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Jul 2008 21:44:38 -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] fix kallsyms to allow discrimination of local symbols


James Bottomley <James.Bottomley@...senPartnership.com> writes:

> [...]  Fix all of this by prefixing local symbols with the actual C
> file name they occur in separated by '|' (I had to use '|' since ':'
> is already in use for module prefixes in kallsyms lookups.  [...]
> Comments?

Can we take some time to review how we got here?


- You disprefer systemtap's use of an established, non-deprecated API
  for placing kernel probes.  (We calculate addresses by a mixture of
  elf-analysis and runtime user-space lookup means.  That's partly
  since kallsyms_lookup was unexported over our objections.)  There is
  nothing outright broken (e.g. incorrect numbers) with what systemtap
  has been doing for years.

- You argue that symbols+offset kprobing is better.  We can see that,
  in some sense, but ...

- I explain that we are used to final address calculating, as we'll
  have to do that regardless for user-space probes.  Plus we need to
  work with kernels that predate the symbol+offset kprobe api
  extension.  So this change would not simplify systemtap in any way.
  You do not respond.

- I offer _stext+offset (for the kernel) and (.text*)+offset (for
  modules) kprobes: basically to use the "better" symbol+offset
  kprobes api, but use the same single reference addresses we already
  do, and leaving just the final addition to the kernel.  You do not
  respond materially.

- You argue that it cannot only be any symbol+offset ... but the actual
  nearest symbol+offset.  But that doesn't work for local symbols.  So
  you fix that to the nearest globally visible symbol+offset.  But this
  requires:
  - yet more extra work and code from systemtap
  - extension to the kernel build system, and kallsyms runtime data to
    fix the current local-symbol-ambiguity problem
  - storage of all that new file name data in permanent unswappable
    kernel data (>>100kB, if done simply prefixing local symbol names
    file file names).
  - possible further complications related to filename string matching

- You have yet to invent a scheme to allow offloading *data* address
  calculations to the kernel.  Without that (and perhaps more),
  systemtap will *still* have to fetch same base _stext etc.
  addresses at run time that it currently does -- even if it did not
  use them to compute kprobes addresses.


In total, this path would end up with both systemtap and the kernel
more complex, larger and a bit slower too.  Does that still seem an
acceptable cost, just to get systemtap to change its preferred kprobes
api?


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