Developing GNOME Applications with Java (Linux Journal) [LWN.net]

Developing GNOME Applications with Java (Linux Journal)

Posted May 27, 2005 23:10 UTC (Fri) by dw (guest, #12017)
In reply to: Developing GNOME Applications with Java (Linux Journal) by bluefoxicy
Parent article: Developing GNOME Applications with Java (Linux Journal)

I'm sorry, but how is your rant applicable to this article? You are talking about the (few potential) vulnerabilities in some specific JRE implementation and constrasting it with a limited range of hardware/OS level bug prevention mechanisms.

Within the context of this article, in comparison to working in raw C, the increased security/productivity offered by Java far outweighs the fact that existing JREs cannot make use of some existing low level stack/memory protection mechanisms that don't even guarantee security anyway.

to post comments

Developing GNOME Applications with Java (Linux Journal)

Posted May 28, 2005 0:44 UTC (Sat) by bluefoxicy (guest, #25366) [Link] (4 responses)

(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.

Developing GNOME Applications with Java (Linux Journal)

Posted May 28, 2005 3:10 UTC (Sat) by mepr (guest, #4819) [Link] (3 responses)

"it's 'infeasable' to break it in a 48 bit address space"

I don't know when I'll seeing a GNOME desktop with 48 bits (256TB) of addressable memory. I'm not sure when I can expect to see such a system with 40 bits of memory (1TB), particularly not a consumer desk top.

Developing GNOME Applications with Java (Linux Journal)

Posted May 28, 2005 7:47 UTC (Sat) by farnz (subscriber, #17727) [Link] (2 responses)

All AMD64 systems have at least a 48-bit virtual address space, if not larger; just because it's not usually backed by RAM doesn't mean an exploit can make assumptions about the layout of virtual memory.

Developing GNOME Applications with Java (Linux Journal)

Posted May 28, 2005 19:33 UTC (Sat) by mepr (guest, #4819) [Link] (1 responses)

A naive exploit would be dumb and assume. Most people have memory sticks of uniform size starting in slot zero and working upward, restricting the likely memory locations, and most k8 motherboards are still highly limited in the amount of _actual_ address space implemented. I still dont see how the large memory space matters until it is implemented in hardware and commonly used.
For example, even the dual core, 4cpu Sun Fire V40z that I'm personally slavering over at this second, maxes at 32GB

Developing GNOME Applications with Java (Linux Journal)

Posted May 29, 2005 7:37 UTC (Sun) by peterh (subscriber, #4225) [Link]

You appear to be confusing virtual address space with physical address space.

It is irrelevant how much memory a computer has, or its location in the physical memory map. Address space randomization techniques work by randomizing the base virtual addresses of a program's segments, making it difficult for an attacker to guess the correct location of the program's code and data segments in the virtual address space. This can be done freely on just about any CPU with an MMU (although CPUs with a larger virtual address space naturally have more possible locations that can be used, irrespective of the size of physical memory).

Note that it is completely irrelevant (beyond a point) how much physical memory is installed and its configuration. These details are only known to the CPU and kernel, not to userspace programs. In fact, one of the main jobs of the kernel is to abstract these details from userspace. I don't know of any technical obstacle to using address space randomization on, say, an 80386 with 4Mb of RAM -- you still have 4Gb of virtual address space to play with on a 32 bit machine (actually 2Gb for userspace, but that's another story).

Take a look at a basic operating systems textbook (eg. Tanenbaum 'Modern Operating Systems') if you want more details.