Then what's the profit?
Posted Nov 1, 2010 15:58 UTC (Mon) by khim
In reply to: Surprisingly enough...
Parent article: A Firefox zero-day vulnerability
I will give you that there are such problems in Sun's JVM as well. I don't think many of them translate into security vulnerabilities though.
These problems are exactly the same as buffer overflow problems in C: yes, there are mitigation techniques, but they don't always help and more vulnerabilities then you can imagine can be exploited. I have a friend who's developing code which is instrumenting .class files. You'll not believe how easy it is to crash the JVM - without even trying. And you want to say this will be our security guard? Don't make me laugh.
Your main argument is that a virtual machine is too complex to be a net benefit for security. I think this has been shown to be false by lots and lots of real world applications.
Languages and technologies chosen for "real world application" (I mean commercial ones) correlate more to the PR budget, not to the quality of stuff. Where technical excellence is more important (FOSS world) Java is not all that popular.
To address your immediate concern about .class vulnerabilities: code could still be distributed in source form.
Then why spend resources with bytecode? Native compilation like V8 works just fine.
seccomp, while very cool, does not solve the problem completely - it just moves it. It is the same as relying on the kernel to be completely bug-free.
Yes, seccomp is not panacea but it's step in right direction. JVM is step in wrong direction, plain and simple.
to post comments)