gcj-security and some issues
Thu Apr 29 14:54:00 GMT 2004
Bryce McKinlay writes:
> I think malicious native code is beyond the scope of the Java security
> model. OS-level security is needed to protect against such things - so
> we're getting into the domain of things like SELinux.
> IMO the security model is needed in libgcj to support:
> - Untrusted bytecode (interpreted, JITted, etc)
> - Native code generated from untrusted bytecode in a trusted compilation
> >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
> 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.
> I'm not sure if reducing the granularity of security checks from the
> class level to the .so level would help that much. The cost of unwinding
> each stack frame (using EH info) to obtain the IP probably far outweighs
> the cost of mapping the IP to a protection domain, regardless of whether
> its at the class or the shared library level.
We already have everything needed to make this work. As I understand
it, your new stack trace infrastructure will make this cleaner, but
will probably have little impact on performance, either positive or
negative. From the point of view of the user, it's a change of
It looks to mke like Jakob's proposal is a good starting point.
More information about the Java