Skip to main content

Help Crack The Java Verifier

Posted by kgh on October 30, 2005 at 6:05 PM PST

Sun is asking the developer community to help
attack the new
bytecode verifier
in Mustang. Here's some background on how
and why the community can help here.

In developing Java SE 6 ("Mustang") we have adopted a more open, community-based, development model. As part of
that we are releasing complete binaries and sources for all our
weekly Mustang builds at
mustang.dev.java.net and
we are also recruiting community contributions into the release.

In previous JDK releases we had waited until the releases were
functionally complete and stable before we released our first
binaries as official betas. And we waited even longer (often until
final release) before making available full source for the releases.
After all, why bother to release incomplete builds or non-final sources? We all want to be seen and judged on our best work,
not on our rough drafts, right?

Well, we were partly right and partly wrong.
There are many customers who are only interested in seeing
the final, stable end product. They want to download something that
will work well for them and they don't want to see the intermediate
development steps. That approach is perfectly valid and makes a lot
of sense for many busy customers. And we don't want to delay or
distract those customers.

Mustang.gif

However, it is also clear that there are many developers who would
like to act as collaborators in helping to make Java SE
better, both by reviewing the work in progress and by actively
contributing code and insight into the release. For that community,
exposing rough drafts makes perfect sense. These are our coauthors
who are helping us create the final work. That is why we created
the mustang.dev.java.net
collaboration site so we could expose interim builds, get feedback,
and incorporate changes from the community.

We've already been receiving a lot of feedback on Mustang based
on the various weekly builds. That has been much appreciated and
has been helping us to tune and adjust the release as we go along.
Thank you.

But now we have come to a particularly scary moment
and a particularly important
opportunity for the community to contribute to Mustang development.
As part of Mustang we will be delivering a whole new classfile verifier
implementation based on an entirely new verification approach.
The classfile verifier
is the very heart of the whole Java sandbox model, so replacing both
the implementation and the basic verification model is a Really Big Deal.
See Gilad Bracha's blog for an overview of the new verifier plus links to the spec.
The new verifier is faster and smaller than the classic verifier, but
at the same time it doesn't have the ten years of reassuring shakedown
history that we have with the classic verifier.

The new verifier led us to an interesting test of our new development
philosophy.
Should we delay exposing the new verifier for as long as possible?
Or should we push it out, advertise it, and ask for the community's
help in reviewing it? Well, I will confess that many of us had an
initial fit of the heebie-jeebies about publishing the source code for
the new verifier. "But what if someone finds an ugly security hole?"
Gasp!

But that question does kind of answer itself, doesn't it?
If someone spots a problem we can fix it and we can fix it
before we finalize the release. Happiness!

We think the new verifier model is sound and we are taking various
steps to review the actual implementation code. But the more eyes
that can look at this before it goes into production use, the better.

As a result, Sun has launched the
Crack the Verifier initiative. Read the
article for more details, but broadly Sun is
looking for security experts and astute hackers in the Java community
who can help review the new verifier and help discover any potential
holes in time for them to be fixed in Mustang.

I hope people will rise to this challenge.
This is definitely a case where broad community involvement can trounce
what any one individual company can hope to do on its own. I hope
this will be an opportunity to demonstrate that community-based
development can really help improve a core area of a key Java technology.

Now, I'll also be extremely happy if what happens is that a lot of
people look at the new verifier and no one finds any holes. That
will be a good outcome! But if there are any holes, let's find
them now...

  - Graham

Related Topics >>