Verifier in 1.5 is definately OFF by default:
to confirm this do the following:
1. Create this class:
======================================
public class Foo {
public static int k = 23;
static {
System.out.println("initially k: " + k);
}
public static void m(){
System.out.println("m() k: " + k);
}
}
======================================
2. Compile it.
3. Create this class
======================================
public class Test {
public static void main(String[] args){
Foo.k = 34;
Foo.m();
}
}
======================================
4. Compile it.
5. Run it like so:
5a. java Test
5b. java -verify Test
6. Change "Foo.java" like so:
======================================
public class Foo {
private static int k = 23;
static {
System.out.println("initially k: " + k);
}
public static void m(){
System.out.println("m() k: " + k);
}
}
======================================
(note "k" is now private).
7. recompile "Foo.java" (DO NOT recompile Test.java")
8. run Test.java like so:
8a. java Test
8b. java -verify Test
Note the differences ...
Tested with
===============================
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
===============================
-- Michael
On 5/4/06, Wall, Kevin <[EMAIL PROTECTED]> wrote:
David Eisner wrote...
> Wall, Kevin wrote:
The correct attribution for bring this up (and the one whom you are
quoting) is Dinis Cruz.
> >> same intuition about the verifier, but have just tested
> >> this and it is not the case. It seems that the -noverify is the
> >> default setting! If you want to verify classes loaded from the
local
> >> filesystem, then you need to explicitly add -verify to the cmd
line.
>
> Is this (still) true? The -verify and -noverify flag are no longer
> documented [1], although they are still accepted.
>
> I did a little experiment (with my default 1.5 VM). I compiled a
> HelloWorld program, then changed a few byes in the class file with a
> hex editor.
Perhaps no longer true (at least one could hope), but I can't take
credit
for the part you quoted above. That was Dinis.
Also, from the results of your test, it seems to indicate that SOME TYPE
of verification is taking place, but if all you did was change a few
ARBITRARY bytes in the .class file, I don't think that proves the
byte code verifier is being being run in it's entirety. IIRC, the
discussion was around the issue of 'type safety'. It's hard to see how
a HelloWorld program would show that.
It's entirely possibly that the (new 1.5) default just does some
surface level of byte code verification (e.g., verify that everything
is legal "op codes" / byte code) before HotSpot starts crunching
on it and that this works differently if either the '-verify' or
'-noverify' flags are used. E.g., suppose that '-verify' flag, does
some deeper-level analysis, such as checks to ensure type safety, etc,
whereas the '-noverify' doesn't even validate the byte codes are
legal op codes or that the .class file has a legal format. This might
even make sense because checking for valid file format and valid
Java "op codes" ought to be fairly "cheap" checks compared to the
deeper analysis required for things like type safety.
You didn't discuss details of what bits you tweaked, so I'm not
quite yet ready to jump up and down for joy and conclude that Sun has
now seen the light and has made the 1.5 JVM default to run the byte
code through the *complete* byte code verifier. I think more tests
are either necessary or someone at Sun who can speak in some official
capacity steps up and gives a definitive word one way or another on
this.
-kevin
---
Kevin W. Wall Qwest Information Technology, Inc.
[EMAIL PROTECTED] Phone: 614.215.4788
"Linux *is* user-friendly. It's just choosy about its friends."
- Robert Slade, http://sun.soci.niu.edu/~rslade/bkl3h4h4.rvw
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
