[BC ABI] gcj-abi-2-dev-branch created
Andrew Haley
aph@redhat.com
Fri Apr 16 18:17:00 GMT 2004
Casey Marshall writes:
> >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
>
> Andrew> Oh yeah, and:
> Andrew> * Security checks. Given that we'll be a "drop in"
> Andrew> replacement, we have to do something about AccessController
> Andrew> and other security sandbox matters.
>
> This is something I have been curious about: how well (if at all)
> java's notion of secure class loading can be mapped to libgcj's
> approach.
>
> I suppose at least you could fill in the CodeSource of a shared
> library, and have access rules based on that, but what about signed
> code? Is it possible to digitially sign shared libraries similar to
> the way one can sign jar files?
>
> And what about verification? Is it even possible to verify compiled
> code like one would verify bytecode?
What you do is this:
The first time you see a class, you verify it in the normal way, and
then compile it to object code. You also save a cryptographic hash of
the class. You also generate assertions for all of the verification
checks you performed, and put them into the compiled code. So, every
time the compiled code is loaded, you execute the verification
assertions. This is cheaper than full verification, but checks
everything you need.
The next time you see a string of bytes that claims to be a class
file, you generate the cryptographic hash of those bytes and see if
you have a compiled binary that corresponds. If you do, you load that
binary and execute its verification assertions. You've verified
everything, and you can now jump to the code.
Andrew.
More information about the Java
mailing list