4 ms·

I'll bite. :-) Java is a perfectly safe language, with one of the best defined specs out there. The JVM, however, has had it's share of vulnerabilities, but tha

I'll bite. :-) Java is a perfectly safe language, with one of the best defined specs out there. The JVM, however, has had it's share of vulnerabilities, but that comes with the territory of being installed on 3 billion devices.

nickpsecurity 10y ago
I'll be nice since you are. Java is well-defined language with safety features. Problem was it's written for inefficient abstract machine hard to implement correctly and with much complexity. That and its libraries are written in an unsafe language. Whereas, languages like Modula-3, Ada, or safe variants of C are straight-forward to map to real hardware with small to no runtimes and libraries in same language. Many checks in by default. Two, C subsets and SPARK, can be proven free of common errors. There's a vast difference in safety between such languages and the Java platform. Complexity of compiler/runtime and unsafe libraries are main reasons. Safety-critical, minimal runtimes exist for Java but they're slow and I doubt you paid $$$ for them. ;)
- ianopolous 10y ago
  What's your opinion of the Graal substrate VM? It is 98% implemented in Java, allows you to precompile a VM exactly for your language, and allows you to exclude the entire Java core libraries, for a super lean, but still highly optimized and safe runtime.
  - nickpsecurity 10y ago
    I look at it tonight when I'm off. Already sounds better than regular platform.
  - nickpsecurity 10y ago
    Damn, had I had this link... http://lafo.ssw.uni-linz.ac.at/papers/2015_CGO_Graal.pdf http://lafo.ssw.uni-linz.ac.at/papers/2015_CGO_Graal.pdf ...I could've replied immediately. Graal keeps HotSpot VM, presumably libraries too, while replacing the JIT with an extra-aggressive one (semantic risk) coded in Java (lower code-risk). It's still bad as it barely addresses platform's overall risk. Might make a better, safer JIT for existing platform. The [potentially] better ones are those designed for high-reliability applications such as Aonix's PERC and JamaicaVM. They tend to try to do less with more predictability. There was one implemented on Oberon called Jaos JVM. Also, although JVM itself is orthogonal to this, you can run your Java program on JX Operating System for higher security. http://www4.cs.fau.de/Projects/JX/ http://www4.cs.fau.de/Projects/JX/
    - ianopolous 10y ago
      Thanks! JX looks very interesting! I double checked and it appears that almost all of the Java core libraries (rt.jar) are indeed already written in Java. (More a point of information than anything else)
      - nickpsecurity 10y ago
        I thought you'd like it. It's GPL'd, too, with active development. Might be worth contributing to or porting to Xen for containerized apps with better security.
    - ianopolous 10y ago
      And digging deeper, the Hotspot VM has ~250k lines of C/C++. This provides: 1) Class loader 2) Bytecode interpreter 3) 2 JITs 4) 3 Garbage collectors 5) High performance synchronization primitives My understanding is that the aim of Graal is to replace the JITs, that Truffle will replace (1) and (2) and the Substrate VM will replace (4) and (5). So most of the C/C++ should disappear. (I don't know what the substrate VM is written in, but it is much smaller regardless)
      - nickpsecurity 10y ago
        Going by this presentation after reading the Graal slides: http://www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf http://www.oracle.com/technetwork/java/jvmls2013wimmer-20140... The documentation of all of them is terrible as there's no clear explanation of Truffle and Substrate: jumps right into technical stuff with a barrage of techniques. Truffle appears to be a toolkit for generating parsers/compilers plus integration interface for the VM's. I don't see mention of replacing class loader and bytecode interpreter. Whereas Graal is a combo, per slide images, of Hotspot bottom parts and Java-based compiler/JIT. It at least has huge code reduction plus safer code over original VM in their illustrations. Only 60Kloc. Going from there, the linked PDF shows Truffle connecting to either GraalVM or Substrate VM. In one slide, it references GraalVM like it's necessary for integrating with Java applications while calling Substrate embeddable. Makes me think Substrate is standalone apps. In another slide, it visually implies that Substrate compiles your code and just Java classes you need into one executable that maybe can't load others. It's not clear if Substrate is reusing the C/C++ code of 1, 2, 4, or 5 from HotSpot for lower layers. All in all, they're doing interesting things but I'm too confused to evaluate them. Do you have any links that are more specific on these issues, esp how SubstrateVM works or whether Graal uses C/C++ code for bottom layers as in picture? I can't evaluate them without even an internal architecture description.

nickpsecurity 10y ago

I'll be nice since you are. Java is well-defined language with safety features. Problem was it's written for inefficient abstract machine hard to implement correctly and with much complexity. That and its libraries are written in an unsafe language. Whereas, languages like Modula-3, Ada, or safe variants of C are straight-forward to map to real hardware with small to no runtimes and libraries in same language. Many checks in by default. Two, C subsets and SPARK, can be proven free of common errors. There's a vast difference in safety between such languages and the Java platform. Complexity of compiler/runtime and unsafe libraries are main reasons. Safety-critical, minimal runtimes exist for Java but they're slow and I doubt you paid $$$ for them. ;)

ianopolous 10y ago
What's your opinion of the Graal substrate VM? It is 98% implemented in Java, allows you to precompile a VM exactly for your language, and allows you to exclude the entire Java core libraries, for a super lean, but still highly optimized and safe runtime.
- nickpsecurity 10y ago
  I look at it tonight when I'm off. Already sounds better than regular platform.
- nickpsecurity 10y ago
  Damn, had I had this link... http://lafo.ssw.uni-linz.ac.at/papers/2015_CGO_Graal.pdf http://lafo.ssw.uni-linz.ac.at/papers/2015_CGO_Graal.pdf ...I could've replied immediately. Graal keeps HotSpot VM, presumably libraries too, while replacing the JIT with an extra-aggressive one (semantic risk) coded in Java (lower code-risk). It's still bad as it barely addresses platform's overall risk. Might make a better, safer JIT for existing platform. The [potentially] better ones are those designed for high-reliability applications such as Aonix's PERC and JamaicaVM. They tend to try to do less with more predictability. There was one implemented on Oberon called Jaos JVM. Also, although JVM itself is orthogonal to this, you can run your Java program on JX Operating System for higher security. http://www4.cs.fau.de/Projects/JX/ http://www4.cs.fau.de/Projects/JX/
  - ianopolous 10y ago
    Thanks! JX looks very interesting! I double checked and it appears that almost all of the Java core libraries (rt.jar) are indeed already written in Java. (More a point of information than anything else)
    - nickpsecurity 10y ago
      I thought you'd like it. It's GPL'd, too, with active development. Might be worth contributing to or porting to Xen for containerized apps with better security.
  - ianopolous 10y ago
    And digging deeper, the Hotspot VM has ~250k lines of C/C++. This provides: 1) Class loader 2) Bytecode interpreter 3) 2 JITs 4) 3 Garbage collectors 5) High performance synchronization primitives My understanding is that the aim of Graal is to replace the JITs, that Truffle will replace (1) and (2) and the Substrate VM will replace (4) and (5). So most of the C/C++ should disappear. (I don't know what the substrate VM is written in, but it is much smaller regardless)
    - nickpsecurity 10y ago
      Going by this presentation after reading the Graal slides: http://www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf http://www.oracle.com/technetwork/java/jvmls2013wimmer-20140... The documentation of all of them is terrible as there's no clear explanation of Truffle and Substrate: jumps right into technical stuff with a barrage of techniques. Truffle appears to be a toolkit for generating parsers/compilers plus integration interface for the VM's. I don't see mention of replacing class loader and bytecode interpreter. Whereas Graal is a combo, per slide images, of Hotspot bottom parts and Java-based compiler/JIT. It at least has huge code reduction plus safer code over original VM in their illustrations. Only 60Kloc. Going from there, the linked PDF shows Truffle connecting to either GraalVM or Substrate VM. In one slide, it references GraalVM like it's necessary for integrating with Java applications while calling Substrate embeddable. Makes me think Substrate is standalone apps. In another slide, it visually implies that Substrate compiles your code and just Java classes you need into one executable that maybe can't load others. It's not clear if Substrate is reusing the C/C++ code of 1, 2, 4, or 5 from HotSpot for lower layers. All in all, they're doing interesting things but I'm too confused to evaluate them. Do you have any links that are more specific on these issues, esp how SubstrateVM works or whether Graal uses C/C++ code for bottom layers as in picture? I can't evaluate them without even an internal architecture description.