You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Bob <ci...@earthlink.net> on 2005/05/10 03:49:57 UTC
Java Security for Harmony
Harmony sounds like a great and well-needed project.
While it's still in its initial stages, I would like to advocate for
the importance of the Java 2 Security Model, and that it is implemented
correctly. Past free Javas have essentially ignored this aspect of
Java. However, the security model is precisely what makes Java more
than simply a subset of C++ with a nice class library. It is what
allows Java to do NEW things that weren't already possible with the old
tools we had, such as GCC.
Java security enables one to build applications that pass around
untrusted and semi-trusted code and have complete control over how it
is going to be run. This is of growing importance in today's world of
distributed computing and viruses. If it is NOT implemented in any
upcoming free Java systems, then Sun's Java will remain the only viable
alternative for what could be the most exciting class of Java
applications.
Implementation requires a "security stack", every layer of which must
be gotten right:
1. Language specification (public/private, pointer safety, etc)
2. Bytecode verifier
3. Correct implementation of classloader semantics (which can be
subtle)
4. Correct implementation of the Java security model (described in Li
Gong's book)
5. Correct implementation of fine-grained permissions (which find
themselves all over the Java library)
Sun's Java has probably gotten these things mostly right, although I've
never seen a security audit, and "security by obscurity" is never to be
trusted. GCJ is fundametnally not appropriate for the implementation
of Java security, due to its ahead-of-time machine code compilation
model. For this reason, I think that a new free JVM should take a
separate path from GCJ (which has its place) and try to stick to Sun's
bytecode/JIT model. On desktop machines, at least, the two seem to run
with comparable speed.
Sincerely,
-- Bob Fischer
Re: Java Security for Harmony
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Tue, 2005-05-10 at 21:40 -0400, Bob wrote:
> Some attention DOES need to be paid to speed. If Harmony is
> consistently 3-5X slower than Sun (which it will be, if there's no JIT
> and no bytecode verifier and no ahead-of-time compiler), then many Java
> apps will simply be too slow to run on Harmony.
Although simple interpreters aren't as speedy as some of the other
execution models out there, the speed of some implementations (notably
gcj) is comparable to other implementations.
See for example:
http://www.shudo.net/jit/perf/
http://www.spindazzle.org/benchmarks/
Cheers,
Mark
Re: Java Security for Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Anthony Green wrote:
> On Wed, 2005-05-11 at 11:47 +0100, Ben Laurie wrote:
>
>>>No, a conforming implementation requires a bytecode verifier.
>>
>>I thought we'd established that it didn't? That is, verification must
>>occur, but it can occur at runtime.
>
>
> I'm sorry, I didn't follow the discussion earlier. My understanding is
> that section 2.17.3 of the Java VM spec mandates that bytecode
> verification happen during the linking stage.
>
> http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#22574
You would appear to be correct. This wouldn't rule out (IMO) some kind
of pre-verification scheme, though.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Java Security for Harmony
Posted by Anthony Green <gr...@redhat.com>.
On Wed, 2005-05-11 at 11:47 +0100, Ben Laurie wrote:
> > No, a conforming implementation requires a bytecode verifier.
>
> I thought we'd established that it didn't? That is, verification must
> occur, but it can occur at runtime.
I'm sorry, I didn't follow the discussion earlier. My understanding is
that section 2.17.3 of the Java VM spec mandates that bytecode
verification happen during the linking stage.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#22574
AG
Re: Java Security for Harmony
Posted by Rodrigo Kumpera <ku...@gmail.com>.
The verifier is part of the the class loading process, it's the first
step of linking a class to the runtime. More about that can be found
in [1], but the verifier makes sure that a given piece of bytecode
won't mess up the stack or incorrectly use types.
Rodrigo
[1] The Java Virtual Machine Specification, Second Edition
On 5/11/05, FaeLLe <mr...@gmail.com> wrote:
> So byte code verification can occur at runtime and still be a confronting
> implementation ?
>
> I think it would make since as long as it occurs because even J2ME pre
> verifies (as i guess you guys know) and that is accepted at run time as long
> as it remains in that state.
>
>
> On 5/11/05, Ben Laurie <be...@algroup.co.uk> wrote:
> >
> > Anthony Green wrote:
> > > On Wed, 2005-05-11 at 10:42 +0100, Ben Laurie wrote:
> > >
> > >>I'm more interested in the modularity with this question - by the sound
> > >>of it, the verifier is an optional module.
> > >
> > >
> > > No, a conforming implementation requires a bytecode verifier.
> >
> > I thought we'd established that it didn't? That is, verification must
> > occur, but it can occur at runtime.
> >
> > --
> > http://www.apache-ssl.org/ben.html http://www.thebunker.net/
> >
> > "There is no limit to what a man can do or how far he can go if he
> > doesn't mind who gets the credit." - Robert Woodruff
> >
>
> --
> www.FaeLLe.com <http://www.FaeLLe.com>
>
>
Re: Java Security for Harmony
Posted by FaeLLe <mr...@gmail.com>.
So byte code verification can occur at runtime and still be a confronting
implementation ?
I think it would make since as long as it occurs because even J2ME pre
verifies (as i guess you guys know) and that is accepted at run time as long
as it remains in that state.
On 5/11/05, Ben Laurie <be...@algroup.co.uk> wrote:
>
> Anthony Green wrote:
> > On Wed, 2005-05-11 at 10:42 +0100, Ben Laurie wrote:
> >
> >>I'm more interested in the modularity with this question - by the sound
> >>of it, the verifier is an optional module.
> >
> >
> > No, a conforming implementation requires a bytecode verifier.
>
> I thought we'd established that it didn't? That is, verification must
> occur, but it can occur at runtime.
>
> --
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Java Security for Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Anthony Green wrote:
> On Wed, 2005-05-11 at 10:42 +0100, Ben Laurie wrote:
>
>>I'm more interested in the modularity with this question - by the sound
>>of it, the verifier is an optional module.
>
>
> No, a conforming implementation requires a bytecode verifier.
I thought we'd established that it didn't? That is, verification must
occur, but it can occur at runtime.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Java Security for Harmony
Posted by Anthony Green <gr...@redhat.com>.
On Wed, 2005-05-11 at 10:42 +0100, Ben Laurie wrote:
> I'm more interested in the modularity with this question - by the sound
> of it, the verifier is an optional module.
No, a conforming implementation requires a bytecode verifier.
AG
Re: Java Security for Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Bob wrote:
> Some attention DOES need to be paid to speed. If Harmony is
> consistently 3-5X slower than Sun (which it will be, if there's no JIT
> and no bytecode verifier and no ahead-of-time compiler), then many Java
> apps will simply be too slow to run on Harmony.
I'm more interested in the modularity with this question - by the sound
of it, the verifier is an optional module.
>
> On May 10, 2005, at 11:41 AM, Ben Laurie wrote:
>
>> Andreas Ravnestad wrote:
>>
>>> Ben wrote:
>>>
>>>> Forgive my ignorance - why is this necessary?
>>>
>>> A few short & sweet reasons see
>>> http://fpl.cs.depaul.edu/cpitcher/se573/lectures/lecture
>>> -07.html#slide013
>>
>>
>> So its an optimisation (and therefore optional), right?
>>
>> --
>> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>>
>> "There is no limit to what a man can do or how far he can go if he
>> doesn't mind who gets the credit." - Robert Woodruff
>>
>
>
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Java Security for Harmony
Posted by Bob <ci...@earthlink.net>.
Some attention DOES need to be paid to speed. If Harmony is
consistently 3-5X slower than Sun (which it will be, if there's no JIT
and no bytecode verifier and no ahead-of-time compiler), then many Java
apps will simply be too slow to run on Harmony.
On May 10, 2005, at 11:41 AM, Ben Laurie wrote:
> Andreas Ravnestad wrote:
>> Ben wrote:
>>> Forgive my ignorance - why is this necessary?
>> A few short & sweet reasons see
>> http://fpl.cs.depaul.edu/cpitcher/se573/lectures/lecture
>> -07.html#slide013
>
> So its an optimisation (and therefore optional), right?
>
> --
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: Java Security for Harmony
Posted by Bob <ci...@earthlink.net>.
> What I'm suggesting is that you can have other relationships that
> generate the same confidence - such as an external verifier that
> signifies that it has done its job by signing the bytecode.
>
I see. Sounds like it would work. But there's more to security than
bytecode verification --- various runtime checks are also required.
How much time on the PDA would be saved if the bytecode verification is
off-loaded to a trusted desktop machine?
Another similar approach would be for the PDA to verify its own
bytecode and then fingerprint it. The second time the same bytecode is
loaded, it could be certain it's good.
Re: Java Security for Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Bob wrote:
>> Ben> Also, curious to know - what about out-of-band verifiers? So, for
>> Ben> example, I verify something on my PC, sign it as verified, then
>> run it
>> Ben> on a Palm, with no verification?
>>
>> My understanding was that there is a new kind of "split verification",
>> where a pre-verifier (or the compiler itself) emits type tables as
>> attributes in the bytecode.
>
> I believe it's known as "Proof Carrying Code" in the literature. The
> compiler provides a "proof" that the code is "good", and then the JVM
> merely has to verify the proof, rather than constructing it from scratch.
That wasn't the relationship I had in mind, though its also interesting.
Essentially there's a reliance relationship[1] between the interpreter
and the verifier. The interpreter relies on the verifier having done its
job - the usual model is that the confidence that this has happened is
caused by them both running in the same executable, and the code path
being such that the verifier is run first.
What I'm suggesting is that you can have other relationships that
generate the same confidence - such as an external verifier that
signifies that it has done its job by signing the bytecode.
Cheers,
Ben.
[1] By this I mean what is often called a "trust relationship" - but I
prefer to frame these in terms of reliance, trust being a rather woolly
and emotionally loaded term.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Java Security for Harmony
Posted by Bob <ci...@earthlink.net>.
> Ben> Also, curious to know - what about out-of-band verifiers? So, for
> Ben> example, I verify something on my PC, sign it as verified, then
> run it
> Ben> on a Palm, with no verification?
>
> My understanding was that there is a new kind of "split verification",
> where a pre-verifier (or the compiler itself) emits type tables as
> attributes in the bytecode.
I believe it's known as "Proof Carrying Code" in the literature. The
compiler provides a "proof" that the code is "good", and then the JVM
merely has to verify the proof, rather than constructing it from
scratch.
Re: Java Security for Harmony
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Ben" == Ben Laurie <be...@algroup.co.uk> writes:
Ben> Also, curious to know - what about out-of-band verifiers? So, for
Ben> example, I verify something on my PC, sign it as verified, then run it
Ben> on a Palm, with no verification?
My understanding was that there is a new kind of "split verification",
where a pre-verifier (or the compiler itself) emits type tables as
attributes in the bytecode. These type tables make verification much
more efficient, as all the special 'jsr' handling and type merging
stuff can just go away.
I haven't heard whether there is a defined way to sign bytecode to
avoid the need for any kind of verification.
I don't think there's any deep reason that verification needs to be
done in an explicit way. For instance, hypothetically you could have
a VM that looks up a class' byte[] representation in a database of
known-valid classes, and then only does the full verification if it is
not seen. (This is not completely trivial due to class loading
oddities, but it could be done by deferring some kinds of type
checking, as gcj does.)
Tom
Re: Java Security for Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Tom Tromey wrote:
>>>>>>"Ben" == Ben Laurie <be...@algroup.co.uk> writes:
>
>
>>>A few short & sweet reasons see
>>>http://fpl.cs.depaul.edu/cpitcher/se573/lectures/lecture-07.html#slide013
>
>
> Ben> So its an optimisation (and therefore optional), right?
>
> Yes. Though in practice it is probably necessary to get acceptable
> performance.
>
> Without a verifier you must track the types of everything on the stack
> and in local variables (if you have a verifier you don't need to do
> this), and do assignability checks on arguments to all method calls,
> qualifying reference for a field lookup, etc.
This might be acceptable for a lightweight JVM, though, so we should
rule it out.
Also, curious to know - what about out-of-band verifiers? So, for
example, I verify something on my PC, sign it as verified, then run it
on a Palm, with no verification?
Cheers,
ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Java Security for Harmony
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Ben" == Ben Laurie <be...@algroup.co.uk> writes:
>> A few short & sweet reasons see
>> http://fpl.cs.depaul.edu/cpitcher/se573/lectures/lecture-07.html#slide013
Ben> So its an optimisation (and therefore optional), right?
Yes. Though in practice it is probably necessary to get acceptable
performance.
Without a verifier you must track the types of everything on the stack
and in local variables (if you have a verifier you don't need to do
this), and do assignability checks on arguments to all method calls,
qualifying reference for a field lookup, etc.
Tom
Re: Java Security for Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Andreas Ravnestad wrote:
> Ben wrote:
>
>>Forgive my ignorance - why is this necessary?
>
>
> A few short & sweet reasons see
> http://fpl.cs.depaul.edu/cpitcher/se573/lectures/lecture-07.html#slide013
So its an optimisation (and therefore optional), right?
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Java Security for Harmony
Posted by Andreas Ravnestad <or...@online.no>.
Ben wrote:
> Forgive my ignorance - why is this necessary?
A few short & sweet reasons see
http://fpl.cs.depaul.edu/cpitcher/se573/lectures/lecture-07.html#slide013
Kind regards,
Andreas Ravnestad
Re: Java Security for Harmony
Posted by Ben Laurie <be...@algroup.co.uk>.
Bob wrote:
> While it's still in its initial stages, I would like to advocate for the
> importance of the Java 2 Security Model, and that it is implemented
> correctly. Past free Javas have essentially ignored this aspect of
> Java. However, the security model is precisely what makes Java more
> than simply a subset of C++ with a nice class library. It is what
> allows Java to do NEW things that weren't already possible with the old
> tools we had, such as GCC.
I'm also interested in ensuring that Harmony can use other security
models, particularly object capabilities.
> 2. Bytecode verifier
Forgive my ignorance - why is this necessary?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Java Security for Harmony
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Bob" == Bob <ci...@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
inaccuracies.
Tom