| News | Features | Interviews |
| Blog | Contact | Editorials |
| Project Sumatra improves Java performance with OpenCL |
| By Thom Holwerda, submitted by MOS6510 on 2012-10-10 23:47:06 |
| "Java is a programming language that allows developers to write once and deploy everywhere - from high-end gaming desktops to smartphones. Its OS-agnostic and widespread nature is one of its strongest selling points, but one area where it can fall flat is performance. Generally, Java applications are not going to perform as well as native applications written for a specific OS. However, thanks to Project Sumatra that performance gap may soon become less of an issue." |
|
| RE[5]: Security |
| By JAlexoid on 2012-10-11 15:36:23 |
|
Well you can't do anything useful for a malicious intent through Java. (Unless you are going to send a few emails or something like it) Edited 2012-10-11 15:36 UTC |
 - Score: 2 |
| RE[6]: Security |
| By kwan_e on 2012-10-11 15:57:53 |
|
> Well you can't do anything useful for a malicious intent through Java. (Unless you are going to send a few emails or something like it) What if the JVM is connected and authenticated to a database when the malicious program gets control. A malicious program can use JDBC to get sensitive information from that database without needing to go native. |
| - Score: 2 |
| RE[7]: Security |
| By Alfman on 2012-10-11 16:43:52 |
|
kwan_e, "What if the JVM is connected and authenticated to a database when the malicious program gets control. A malicious program can use JDBC to get sensitive information from that database without needing to go native." Can you elaborate the specifics of where this malicious program came from? The reason I ask is because we need to ask whether the same attack vector is significantly more likely to happen in java than a non-java program. Did the administrator unknowingly install the malicious program in the first place? Did he install a trusted program that contains a remotely exploitable application vulnerability, which enables a remote attacker to install & execute the malicious instructions? Does the compiler contain a bug that can be exploited remotely execute malicious instructions? All these things are possible, but ask yourself if Java is inherently less secure than other languages for running local programs. Escaping java's sandbox is bad, but are there any instances where using Java is worse for security than using another languages like C, which doesn't have any sandbox whatsoever? Is there something specific you think I'm overlooking? |
| - Score: 2 |
| RE[8]: Security |
| By kwan_e on 2012-10-11 16:59:49 |
|
> All these things are possible, but ask yourself if Java is inherently less secure than other languages for running local programs. Escaping java's sandbox is bad, but are there any instances where using Java is worse for security than using another languages like C, which doesn't have any sandbox whatsoever? Is there something specific you think I'm overlooking? I would think that having a portable malicious program is a completely different kind of worse. Java (but you can probably say the same for other cross platform VMs) runs almost the same on any platform, basically amounting to a monoculture. Whereas a C program would be hard pressed to work exactly as designed even for POSIX compliant operating systems, let alone in a realistic environment where there's a mix of different server operating systems. |
| - Score: 2 |
| RE[9]: Security |
| By Alfman on 2012-10-11 18:04:52 |
|
kwan_e, "Java (but you can probably say the same for other cross platform VMs) runs almost the same on any platform, basically amounting to a monoculture." Oh ok...yeah I guess monocultures can be bad for security, competing implementations and variety can help limit the scope of a given attack. The same should be said for operating systems, applications, hardware vendors, etc. We do have some choice in JVM's today. If I were to guess, the Java diversification is probably somewhere between PHP (few competing implementations) and Javascript (many competing implementations). Who knows if we should count android or not, it is a Java language implementation after all, even if its files are not binary compatible. |
| - Score: 2 |
| RE[6]: Security |
| By moondevil on 2012-10-11 18:55:46 |
|
Graal: http://openjdk.java.net/projects... http://www.oracle.com/technetwor... Graal is based on Maxime's work, https://wikis.oracle.com/display/... > I wasn't aware, that's very interesting. I wonder how you bootstrap such a thing. Do you need another VM to bootstrap the Maxime JIT's code? In a way yes. This paper provides a nice overview how bootstraping works, https://wikis.oracle.com/display/... The idea is quite simple, you use the JIT compiler offline to generate the basic VM image for the classes that take care of the VM ground work. The compiler recognises special annotations that allow trusted Java code to perform unsafe operations, this minimizes the requirements to native methods. Additionally you have a thin layer for the native methods. Another example is the Jikes RVM, http://jikesrvm.org/Presentation... What I miss is that the official JDK still lacks an AOT compiler, while other vendors do offer them. It is not easy to convince project managers to pay for native code compilers for Java, unless the project really requires them. > I'm not ready to stop calling it Sun's VM ;) I used to write Sun/Oracle VM in the last months, but one needs to face the sad reality that Sun is gone. |
| - Score: 2 |
| RE[7]: Security |
| By JAlexoid on 2012-10-12 00:39:50 |
|
It's not like it's one JVM for the whole OS. And there is no local IPC mechanism in Java. If the JVM is connected to a DB, then you it's already within your sandbox. At most what you could do is steal the encrypted trusted keystore at most(quite useless without a targeted attack). |
| - Score: 2 |
| RE[8]: Security |
| By kwan_e on 2012-10-12 02:43:13 |
|
> If the JVM is connected to a DB, then you it's already within your sandbox. So as long as the malicious program is in a sandbox, you wouldn't mind it having full access to the database's data? You do realize that the biggest reward to be gained from security breaches is information, not control, right? |
| - Score: 2 |
| RE[9]: Security |
| By moondevil on 2012-10-12 07:34:14 |
|
If the application does not validate the input it gets from the outside world, nasty things will happen even within a sandbox environment. For example, if the application reads SQL from somewhere, it better pre-parse those SQL strings, otherwise something other than the developer expected will happen. Many sandboxed environments, including Java and .NET, do have the possibility to enforce security at the method level, but this is usually only done in enterprise applications. And even then, the developer should take care of validating the input anyway. The security issues with languages like C, is that it is enough for someone to miscalculate one pointer manipulation to expose the application. Other more type safe languages usually force the hacker to manipulate the generated assembly code to achieve the same exploit. The situation will only improve when C and C++ disappear from the tooling stack, or when everything is sandboxed, micro-kernel style. But then we are again back to the problem that even with, lets call it, Safe C, the developer is not off the hook to validate the application's inputs. |
| - Score: 2 |
| RE: Performance is not definitive |
| By Soulbender on 2012-10-14 03:28:07 |
|
> Java performance is not an issue If it feels slow and reacts slow...then it is slow. Pretty much every single Java application I've ever used, server as well as desktop, pretty much used up all the RAM and ran like molasses. > (there's a ton of benchmarks Benchmarks are like asshole; everybody has one and you'll be happier caring only about your own. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |