walking the stack

walking the stack

[Anthony Green]

I've been experimenting with an implementation of the Java's sandbox
design.

The idea is to map ProtectionDomains to PC ranges.  I determine PC
ranges by modifying libgcj.spec to link jrtbegin.o and jrtend.o before
and after all other files.  These object files contain the bits
necessary to determine the range of code needing registration with the
runtime.  For interpreted code I just need to register the closure stub.

Running a check for a priviliged action involves walking the stack and
examining the details of the appropriate ProtectionDomains along the
way.  My current experiments involve using glibc's backtrace()
function.   My questions...

1) Is this reliable on all glibc ports?

2) Is there some better way to get stack trace info?  Like using the
DWARF2 data if it exists.

3) Is there a better way to do all of this?


Thanks,

AG

Re: walking the stack

[Bryce McKinlay]

Anthony Green wrote:

>I've been experimenting with an implementation of the Java's sandbox
>design.
>
>The idea is to map ProtectionDomains to PC ranges.  I determine PC
>ranges by modifying libgcj.spec to link jrtbegin.o and jrtend.o before
>and after all other files.
>

Interesting. I was thinking of something similar for stack trace 
printing, as an alternative to the dlsym/addr2line/demangling stuff we 
do now. That would allow us to get a trace even from a stripped binary 
by utilizing the reflection data.

>2) Is there some better way to get stack trace info?  Like using the
>DWARF2 data if it exists.
>

I don't know how portable backtrace() is, but obviously using the DWARF2 
unwind data would be better, since it is used on more targets than glibc is.

RTH has said that it wouldn't be difficult to add an interface to the 
unwinder which walks the stack without actually unwinding. We want this 
functionality for getting EH stack traces as well.

If we made that interface something like:

_Unwind_TraceStack(void **pc_array, int count)

then we could pass in a pc_array of length 2 and it would only unwind 2 
frames, which would be more efficient for security checks.

regards

Bryce.

walking the stack

[Andrew Haley]

Anthony Green writes:
 > I've been experimenting with an implementation of the Java's sandbox
 > design.
 > 
 > The idea is to map ProtectionDomains to PC ranges.  I determine PC
 > ranges by modifying libgcj.spec to link jrtbegin.o and jrtend.o before
 > and after all other files.  These object files contain the bits
 > necessary to determine the range of code needing registration with the
 > runtime.  For interpreted code I just need to register the closure stub.
 > 
 > Running a check for a priviliged action involves walking the stack and
 > examining the details of the appropriate ProtectionDomains along the
 > way.  My current experiments involve using glibc's backtrace()
 > function.   My questions...
 > 
 > 1) Is this reliable on all glibc ports?

It doesn't work everywhere, but where it is implemented it works well.
It depends on the ABI.

 > 2) Is there some better way to get stack trace info?  Like using the
 > DWARF2 data if it exists.

Yes.

 > 3) Is there a better way to do all of this?

There sure is: David Mosberger's libunwind.

Andrew.

walking the stack

[Andrew Haley]

Andrew Haley writes:
 > Anthony Green writes:
 >  > I've been experimenting with an implementation of the Java's sandbox
 > 
 >  > 3) Is there a better way to do all of this?
 > 
 > There sure is: David Mosberger's libunwind.

I forget to mention: this library isn't yet ready, but it looks very
promising.  I'm as sure as I can be it's the right way to go.

Andrew.

Re: walking the stack

[Adam Megacz]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> That would allow us to get a trace even from a stripped binary by
> utilizing the reflection data.

Is there any way to get line numbers this way, or would the stack
trace be limited to class/method names?

  - a

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: walking the stack

[Anthony Green]

On Mon, 2002-04-15 at 01:37, Bryce McKinlay wrote:
> Interesting. I was thinking of something similar for stack trace 
> printing, as an alternative to the dlsym/addr2line/demangling stuff we 
> do now. That would allow us to get a trace even from a stripped binary 
> by utilizing the reflection data.

I don't think what I'm doing will give you enough resolution.  I just
put jrtbegin and jrtend around crtbegin and crtend to determine the
extent of the text section for the main executable and every shared
library it loads.  This will definitely work for ELF systems.  I don't
know how to do this for Win32.

There's also two other special PC ranges, AccessController.doPrivileged
and the reflection code for invoking methods.  If we come across
AccessController.doPrivileged while walking the stack, then we stop at
its caller's stack frame (unless it's the reflection code, in which
case, we keep on going 'til we're not in the reflection code). 

libunwind sounds perfect if it lets me do callbacks at each stack
frame.   I'll just keep using backtrace() for now until libunwind, or
something like it, becomes available.

-------------------------------------------------------------------------
#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile: %(startfileorig) jrtbegin.o

%rename endfile endfileorig
*endfile: jrtend.o %(endfileorig) 

%rename lib liborig
*lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) %(liborig)

*jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ -fkeep-inline-functions

-------------------------------------------------------------------------

// jrtbegin.cc -- Java Runtime Support

/* Copyright (C) 2002  Free Software Foundation

   This file is part of libgcj.

This software is copyrighted work licensed under the terms of the
Libgcj License.  Please consult the file "LIBGCJ_LICENSE" for
details.  */

#include <config.h>
#include <jvm.h>
#include <java/lang/Thread.h>

static int constr ();

static void *jtb_list[]
  __attribute__ ((unused, section(".jtb"), aligned(sizeof(void*))))
  = { (void *) &constr };

static int
constr ()
{
  _Jv_RegisterProgramTextRange 
    (jtb_list[0], jtb_list[1],
     gcj::runtimeInitialized ?
     java::lang::Thread::currentThread()->getContextClassLoader() : 0);
  return 0;
}

// This horrible hack is used to force the generation of a constructor
// function to call constr().  If g++ supported the constructor function
// attribute we wouldn't have to resort to this.
static int why_doesnt_gxx_support_constructor_function_attributes = 
  constr ();

-------------------------------------------------------------------------

// jrtend.cc -- Java Runtime Support

/* Copyright (C) 2002  Free Software Foundation

   This file is part of libgcj.

This software is copyrighted work licensed under the terms of the
Libgcj License.  Please consult the file "LIBGCJ_LICENSE" for
details.  */

// Force C++ compiler to use Java-style exceptions.
#pragma GCC java_exceptions

static int jrt_end_text __attribute__((section(".text")));

static void *jtb_list_1
  __attribute__((unused, section(".jtb"), aligned(sizeof(void*))))
  = (void *) &jrt_end_text;

-------------------------------------------------------------------------

Re: walking the stack

[Anthony Green]

On Mon, 2002-04-15 at 02:59, Andrew Haley wrote:
>  > 3) Is there a better way to do all of this?
> 
> There sure is: David Mosberger's libunwind.

I found the source on BitKeeper.  It's GPLd right now.  However, the
notes say that he'd like to see it merged into the GCC runtime which
means he'll have to change the license anyway.

AG

Re: walking the stack

[Bryce McKinlay]

Anthony Green wrote:

>On Mon, 2002-04-15 at 01:37, Bryce McKinlay wrote:
>
>>Interesting. I was thinking of something similar for stack trace 
>>printing, as an alternative to the dlsym/addr2line/demangling stuff we 
>>do now. That would allow us to get a trace even from a stripped binary 
>>by utilizing the reflection data.
>>
>
>I don't think what I'm doing will give you enough resolution.  I just
>put jrtbegin and jrtend around crtbegin and crtend to determine the
>extent of the text section for the main executable and every shared
>library it loads.
>

Right. For stack tracing the idea was to use the (sorted, perhaps, if 
they arn't already) method pointer values in the reflection data to 
determine what method a given PC value belongs to.

It seems to me that this technique would be more flexible and portable 
than using jrtbegin/jrtend. Once you have the class that a PC value 
belongs to you can just call getProtectionDomain() on it.

Of course, for native code, there is really no way to enforce java 
security since any .so you load might have hacks in it which bypass the 
security checks and do anything they want to the runtime. Thus 
implementing security is really only useful for applications which 
depends on having it to run. And, of course, for bytecode.

regards

Bryce.

Re: walking the stack

[Bryce McKinlay]

Adam Megacz wrote:

>Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>
>>That would allow us to get a trace even from a stripped binary by
>>utilizing the reflection data.
>>
>
>Is there any way to get line numbers this way, or would the stack
>trace be limited to class/method names?
>

No, there would be no way to get line number info from a stripped binary 
- it would just be class/method names.

regards

Bryce.

Re: walking the stack

[Bryce McKinlay]

Anthony Green wrote:

>On Mon, 2002-04-15 at 02:59, Andrew Haley wrote:
>
>> > 3) Is there a better way to do all of this?
>>
>>There sure is: David Mosberger's libunwind.
>>
>
>I found the source on BitKeeper.  It's GPLd right now.  However, the
>notes say that he'd like to see it merged into the GCC runtime which
>means he'll have to change the license anyway.
>

Hmm, It had the GPL+exception libgcc licensed last time I checked.

regards

Bryce.

Re: walking the stack

[Adam Megacz]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> > Is there any way to get line numbers this way, or would the stack
> > trace be limited to class/method names?
> 
> No, there would be no way to get line number info from a stripped binary 
> - it would just be class/method names.

So would it make sense to have a three stage fallback here
(DWARF2->addr2line()->reflection_data)?

  - a

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: walking the stack

[Bryce McKinlay]

Adam Megacz wrote:

>Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>
>>>Is there any way to get line numbers this way, or would the stack
>>>trace be limited to class/method names?
>>>
>>No, there would be no way to get line number info from a stripped binary 
>>- it would just be class/method names.
>>
>
>So would it make sense to have a three stage fallback here
>(DWARF2->addr2line()->reflection_data)?
>

Yeah - although ideally we'd be able to get rid of addr2line alltogether 
if we can do dwarf2. It would also be good to have some way to recognise 
interpreter/JIT frames and call into them for their own stack info.

regards

Bryce.

Re: walking the stack

[Brian Jones]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> Adam Megacz wrote:
> 
> >Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> >
> >>>Is there any way to get line numbers this way, or would the stack
> >>>trace be limited to class/method names?
> >>>
> >> No, there would be no way to get line number info from a stripped
> >> binary - it would just be class/method names.
> >>
> >
> >So would it make sense to have a three stage fallback here
> >(DWARF2->addr2line()->reflection_data)?
> >
> 
> Yeah - although ideally we'd be able to get rid of addr2line
> alltogether if we can do dwarf2. It would also be good to have some
> way to recognise interpreter/JIT frames and call into them for their
> own stack info.

Given that with exception reporting you're only talking about
package/class/method/line numbers couldn't these bits be extracted
when compiling .java or .class and stored somewhere for this purpose?
With the .so, .dll, or executable seems elegant and maybe this is what
DWARF2 is.  

Brian
-- 
Brian Jones <cbj@gnu.org>

Re: walking the stack

[Andrew Haley]

Bryce McKinlay writes:
 > Adam Megacz wrote:
 > 
 > >Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
 > >
 > >>>Is there any way to get line numbers this way, or would the stack
 > >>>trace be limited to class/method names?
 > >>>
 > >>No, there would be no way to get line number info from a stripped binary 
 > >>- it would just be class/method names.
 > >>
 > >
 > >So would it make sense to have a three stage fallback here
 > >(DWARF2->addr2line()->reflection_data)?
 > >
 > 
 > Yeah - although ideally we'd be able to get rid of addr2line
 > alltogether if we can do dwarf2.

In the context of stack unwinding, DWARF 2 refers to the unwind data
that the runtime uses, not information used by a debugger.  Modulo
IA-64, our unwinder runtime uses DWARF 2 unwind info regardless of
whatever format is used for debug info.  Therefore, something that can
read debug info to get line numbers will still be needed.

 > It would also be good to have some way to recognise interpreter/JIT
 > frames and call into them for their own stack info.

Oh yes.

Andrew.

Re: walking the stack

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> Yeah - although ideally we'd be able to get rid of addr2line
Bryce> alltogether if we can do dwarf2. It would also be good to have
Bryce> some way to recognise interpreter/JIT frames and call into them
Bryce> for their own stack info.

Anybody working on this: please look at ORP to see what they do.  We'd
like to plug ORP in to libgcj eventually; making choices up front to
make this easier would be convenient.

Tom