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

Developing GNOME Applications with Java (Linux Journal)

Posted May 28, 2005 3:10 UTC (Sat) by mepr (guest, #4819)
In reply to: Developing GNOME Applications with Java (Linux Journal) by bluefoxicy
Parent article: Developing GNOME Applications with Java (Linux Journal)

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

to post comments

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.