Developing GNOME Applications with Java (Linux Journal)
Developing GNOME Applications with Java (Linux Journal)
Posted May 28, 2005 0:44 UTC (Sat) by bluefoxicy (guest, #25366)In reply to: Developing GNOME Applications with Java (Linux Journal) by dw
Parent article: Developing GNOME Applications with Java (Linux Journal)
(3) together with (2) guarantees that no code can be directly injected into memory (hence java/mono not working); (1) and (4) are probablistic and solvable by luck, typically compounded, producing a multiple of both probabilities that being 2^32 * 2^16 == 2^48, which is pretty much proven to be considered a guarantee (according to an article about address space layout randomization and brute forcing it in 216 seconds in a 32 bit address space; it's "infeasable" to break it in a 48 bit address space). (1) alone bolsters the rest in many cases; (4) guards against the technique used to defeat (2) and (3). The result is reciprocative; each part protects against the attacks needed to defeat the others. Defeat is only possible by breaking (1) and (4), which is highly unprobabilistic.
Inherent security in Java is about as good as inherent security in an operating system. I can't develop a complete JRE/JIT on my own, and nobody is going to be crazy enough to back me on a high-security JIT even if it can provably avoid any performance detriment. I've informed the Mono and Kaffe projects of potential changes. Kaffe looked, made a little noise, no results; Mono just argued that it'd be slow and that no algorithms would ever mitigate that. My solution was to generate all methods called by a method when calling it, and keep track; this would work in theory because at most every other call would generate something, recursion would be fast, and typical access patterns would probably not cause a bunch of functions to exist with perfectly unique calls. Of course it and the two-level-deep model were blanketted with "That Won't Work Because We Said So And We Know More Than You" argument.
As for relavence, I was pointing out that having everything written in Java or C# isn't automatically a Good Thing(TM). The typical results with these types of articles is a double-edged religious battle between "OMFG JAVA IS SLOW AND TEH SUX" and "OMFG JAVA IS THE BEST THING EVAR ITZ SO EZ!"
I was raising the valid concerns of running Java in a secure environment; most typical JIT designs for Java or Mono or anything else won't fit in with a really good security model. These security models are almost but not quite perfectly suitable for even use on a typical home desktop (they kill Java, Mono, and anything using nVidia's closed source GLX; nVidia's GLX would be easy to fix if we had the source, but the other two need serious redesign). Having half your apps get quick and dirty kills by your security system makes these designs infeasible. The only potential saving grace would possibly be gcj.
