How Java works JIT, Just In Time Compiler ● The java compiler takes a .java file and generates a .class file ● JVM ultimately translates bytecode into native code, each time ➤ The .class file contains Java bytecodes, the assembler the same bytecodes are processed, the translation into native language for Java programs code must be made ➤ Bytecodes are executed in a JVM (java virtual machine), ➤ If we can cache translated code we can avoid re-translating the valid bytecodes are specified by Sun the same bytecode sequence • What if third parties create platform/OS specific codes? ➤ Why not just translate the entire .java program into native code? ● The JVM interprets the bytecodes ➤ JVM is platform/OS specific, must ultimately run the code ● Still need the JVM, the JIT works in conjunction with the JVM, not in place of it ➤ Different JVMs will have different performance, JITs are part of the overall JDK/Java performance ● How are classes loaded into the JVM? Can this be thwarted? Duke CPS 108 14.1 Duke CPS 108 14.2 Loading .class files The ClassLoader ● The bytecode verifier “proves theorems” about the bytecodes ● The “Primordial” loader is built-in to the JVM being loaded into the JVM ➤ Sometimes called the “default” loader, but it’s not ➤ These bytecodes may come from a non-Java source, e.g., extensible or customizable the way other loaders are compile Ada into bytecodes (why?) ➤ Loads classes from the platform on which the JVM runs ● This verification is a static analysis of properties such as: (what are loader and JVM written in?) ➤ .class file format (including magic number 0xCAFEBABE) ➤ Methods/instances used properly, parameters correct ● Applet class loader, RMI class loader, user loaders ➤ Stack doesn’t underflow/overflow ➤ Load .class files from URLs, from other areas of platform ➤ … on which JVM runs ● Verification is done by the JVM, not changeable as is, for ➤ What’s the order of sources consulted for loading, does example, the ClassLoader this make a difference? ● Why implement a custom loader? http://securingjava.com ➤ Work at Duke with JOIE http://java.sun.com/sfaq/verifier.html Duke CPS 108 14.3 Duke CPS 108 14.4 The Java ClassLoader Security Manager ● Applets use a SecurityManager ➤ Query for permissions ➤ Supported by browsers by convention (would you use an “untrusted” browser) ● The picture shows JDK 1.0 model, “sandbox” restrictions supported by SecurityManager ➤ Untrusted code restricted to the sandbox ➤ All downloaded/applets are untrusted ➤ Severely limits what a downloaded program can do Duke CPS 108 14.5 Duke CPS 108 14.6 SecurityManager changes in JDK 1.1 SecurityManager changes in JDK 1.2 ● Applets support signing using ● Policies are now supported digital signatures ➤ Allow more fine-grained ➤ Signature stored with code control of access, in JAR file that’s permission downloaded ➤ Based on location (URL) ➤ Clients support open/full and/or digital signatures access to “trusted” applets, ➤ Uses public/private key, some signatures ok applets don’t need to be ● Still “all-or-nothing”, an applet signed, can be from a is untrusted or completely trusted location trusted ● Set policies on a systemwide ➤ What might be preferable? basis using policytool ➤ What about user-level permissions? Duke CPS 108 14.7 Duke CPS 108 14.8.