harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: Java Security for Harmony
Date Tue, 10 May 2005 02:12:03 GMT
>>>>> "Bob" == Bob  <citibob@earthlink.net> writes:

Bob> While it's still in its initial stages, I would like to advocate for
Bob> the importance of the Java 2 Security Model, and that it is
Bob> implemented correctly.

I wouldn't worry about this too much, I think it is implicit in the
goal of having a complete implementation.

It is true that the current free implementations don't really address
this fully.  We're looking at this as an important task for libgcj
over the next year or so; at least, a few of us are trying to push a
Mozilla plugin as an important app, which entails handling this.

Bob> Implementation requires a "security stack", every layer of which must
Bob> be gotten right:

Thanks for the list.  In addition to audits and the like, I really
want to see comprehensive free test suites for all these components
(some of these are notably missing at the moment).

Bob>   1. Language specification (public/private, pointer safety, etc)

This is usually handled by the core part of the VM.  This is
something I think we could share.

Bob>   2. Bytecode verifier

There's a (reasonably) pluggable verifier in gcj (the pluggable
refactoring is on the gcjx branch).

Bob>   5. Correct implementation of fine-grained permissions (which find
Bob>      themselves all over the Java library)

Most of this is done in Classpath, but it could use an audit.
Some of these checks are still missing in the divergent parts of libgcj.

Bob> GCJ is fundametnally not appropriate for the
Bob> implementation of Java security, due to its ahead-of-time machine code
Bob> compilation model.

With the new binary compatibility ABI, this is no longer true.  We can
do full checking with no trouble.  We have even written the compiler
to emit type assertion tables, to duplicate the runtime effects of
verification (without the expense).

I'm not trying to push gcj here, and this doesn't eliminate other
reasons one might prefer JITting... I just wanted to avoid propagating


View raw message