Java patch status

[John Levon <levon@mo...>]

As requested, here's a write-up on the problems with the current Java
patch.

Problems
--------

- first off, the patch doesn't work - I get lots of sections in the ELF
  file, and the symbols look all off. I couldn't get it to work at all.

- it requires you to run Java as root. This is a big deal, we shouldn't
  encourage this sort of thing.

- it requires the opreport user to be root. Same deal.

- the interface isn't acceptable; we can expect at least one other user
  and probably more. See my mail on libagent, and my comments below.

- we could probably do more to detect Java, and install libopjan.so in
  the right place (also, I'd prefer a less obscure name -
  'liboprofile.so' ? Then you'd have -Xrunoprofile)

- as mentioned, the offsets are all wrong. See below.

What we can do about it
-----------------------

This is likely incomplete. These are just my thoughts, perhaps things
could be done differently in some cases.

Introduce agents/java/ - this just hooks into the JVM like opjan does
now, and uses the libagent API. Pretty simple to modify the existing
code, should only take a week maximum.

Introduce libagent. This would have an API similar to the one I've
already suggested. It would live in libagent/ in the sources, and it
would be usable by non-root.

This libagent would track the process's anon regions, as well as the
mappings (symbols) that the agent tells us about.  A written ELF file
consists of a number of sections: each section corresponds to an anon
mapping (*not* a symbol). It has a VMA corresponding to the VMA start of
the anon mapping, and a suitable size. The pp tools already have code
(now) that allows us to handle such ELF files correctly. Neither the pp
tools nor oprofiled need modification.

Of course, we would also write out the symbol table, and, later on, the
machine code for each symbol.

We would write the ELF files under the following circumstances:

- class unload (probably)
- explicit or implicit close of the agent handle
- opcontrol --dump
- others?

Re-introduce the code to rewrite an anon sample file's image to the one
in /var/lib/oprofile/samples/{anon}/... I've already got this small
change in the BRANCH_ANON_MAPPING tree, please ask if you'd like to see
it.

There are still some troublesome security issues. My suggestion (which
I've just thought of, and may have a fatal flaw or two) is as follows:

1) introduce a world-writable, sticky, /var/lib/oprofile/{exec}/.
libagent writes the ELF files there. Then, to make a file 'live', it
fires off a suid helper application. This application is passed the
relevant ELF filename. It examines this to find the tgid of the Java
process. Then, it does getppid() to get the tgid of the process that
exec()'d the helper: iff the process is ancestor of the Java process,
then a symbolic link from /var/lib/oprofile/{anon}/path/to/jit/<tgid> to
/var/lib/oprofile/{exec}/path/to/jit/<tgid> for that ELF file is
created. Thus:

- the suid code is truly minimal
- user file quotas are still observed (ok, you can flood the dir with
  lots of symlinks, but I don't see a way around that)
- a process can't pretend to be an agent for a random Java process, only
  its children

Note that this also lets us start a Java app /before/ oprofiled, and
still get results.

Comments?

regards,
john

Re: separating kernel code <-> user code

[Carl Love <carll@us...>]