Re: gcj-security and some issues

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > > > >It would be interesting  if
 > > > >the compiler could put the start and the end adress (pc) (perhaps
 > > > >relative adress, for relocation and so on) of the methods that were
 > > > >written in java in a write protected memory area (in the constant
 > > > >region).
 > > > 
 > > > The compiler already does this, as part of the DWARF2 unwind info. The 
 > > > tricky part is mapping the function to the class it belongs to. 
 > > > Currently this is done with a hash table but possibly we can add 
 > > > something to the FDE (LDSA?) to make it more efficient.
 > >
 > >The unwinder uses a binary search on each PC value in a stack frame to
 > >locate the start of the function.  Going from there to a class is a
 > >relatively small thing.
 > 
 > Well, you'd think so, but this is the reason why my patch is taking so 
 > long - it becomes complicated because of the Linker/PLT messing function 
 > pointers up.

Right, but the unwinder we have already does basically the same thing
and it's fine except for native methods, which are outside the sandbox
anyway.  Sure, it would be nice to have an accurate mapping of
method->class for native methods, but java.security doesn't require
it AFAICS.

 > Besides that, it takes a reasonable amount of code (potentially
 > during startup if a stack trace is needed) and a not insignificant
 > amount of locking and memory use to build up the hash table that is
 > used to do this mapping.

True.  But hash table insertion isn't that expensive as a portion of
all the stuff we do when initializing a class.  I gues...

Andrew.