Re: Capabilities done right [diff against 2.3.1]

Jeremy Fitzhardinge (jeremy@goop.org)
Tue, 18 May 1999 14:36:27 -0700 (PDT)


On 18-May-99 Theodore Y. Ts'o wrote:
> Why it is it impossible to apply to existing executables? Sure, you'd
> have to pull apart the ELF executable and add some extra code (which
> would obviously be architecture speccific, since it would include
> machine code) to the text segment, but I don't think it's *impossible*.

Everything is generally jammed together, so there's not much space to manoever.
Its easy enough to add new code - just add a new loadable segment - but adding
to the ctor table is harder. There's two approaches:

1. you could extend the ctor table, since you'd basically have to parse the
whole program to work out what pointers to tweak, and even then it might not be
possible (certainly not possible in theory, but more likely in practice). This
would be highly dependent on architecture, language and compiler.

2. you just hijack the first ctor entry, and remember to call the original
contents from your new ctor.

3. copy and augment the ctor table. Copy the ctor table to somewhere else in
the executable/address space, and change the code which points to it. This is
probably relatively easy, though still architecture-specific. I don't know
enough about how ctors are actually called to be sure.

1 is just too complex and fragile to be worth considering. 2 is moderately
easy, but it depends on there being at least one ctor, which may not be the
case. 3 is probably about as hard as 2 to do, but it can deal with ctor-less
executables.

All in all, they're all pretty complex things to do to a live ELF executable,
and not something that I, as an administrator, would want to do to a system.
It would be some work to make it robist against gcc/libc version shifts, on
arbiary binaries from uncertain sources generated by unknown means.

J

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/