SoylentNews is people
SoylentNews
Oracle insists it really is going to sell computers powered by Sparc M7 processors – the same chips it started talking about in 2014.
On Monday, Big Red breathlessly unveiled hardware powered by the beefy microprocessor, and on Tuesday, its supremo Larry Ellison lauded the 64-bit CPU's security defenses.
One of these defenses certainly caught our eye: the ability to tag regions of memory so software hijacked by hackers cannot read or write data it isn't supposed to. This should, we're told, render vulnerabilities such as Heartbleed useless to attackers – more on that in a moment.
[...] The M7 has a defense mechanism called Silicon Secured Memory (SSM) which seems incredibly similar to Oracle's Application Data Integrity (ADI) technology.
ADI works like this: when an application requests some new memory to use via malloc(), the operating system tags the block of memory with a version number, and gives the app a pointer to that memory. The pointer also contains the version number, which is stashed in the top four bits. (A 64-bit pointer doesn't use all 64 bits: the most significant bits are usually all 1s or 0s, and can be used to store metadata.)
Whenever a pointer is used to access a block of memory, the pointer's version number must match the memory block's version number, or an exception will be triggered. The version numbers are checked in real-time by the processor with a tiny overhead – an extra one percent of execution time, according to Oracle's benchmarks.
(Score: 0) by Anonymous Coward on Friday October 30 2015, @12:22AM
I guess we really do repeat history.
I had an 8-bit mahine by IBM, it could house 7MB of memory, but a program would only use 64KB. It used the same trick (mostly). It had 24 bit address registers, but you only colud use 16 bits and the top 8 would be x80. Buy having a priveledge program, (object had a speical bit set in the directory), you could use x00-x7f in the high order and get to all the memory on the machine. If the x80 was set then your memory request would be mapped to region that your program was running. Hi-tech 1980's.
(Score: 2) by captain normal on Friday October 30 2015, @05:16AM
Oh yeah, I remember those. The program was on a 5.25 inch floppy that was read only. And you had to stop every so often to save to another floppy.
When life isn't going right, go left.
(Score: 0) by Anonymous Coward on Friday October 30 2015, @01:44PM
We used 8" diskettes. 10 were fixed into a magazine.
(Score: 3, Informative) by VanderDecken on Friday October 30 2015, @06:52AM
As described on the cryptography [metzdowd.com] mailing list:
What Oracle (Sun) has done here is quite a bit different from the Burroughs tagged memory. [...]
The hardware is storing an extra software-controlled 4-bit value along with each 64-byte cache line in main memory. When enabled, hardware compares this value to the top bits of the address being used to access the memory, and faults if they don't match. This is an interesting use of the copious spare bits available in 64-bit addresses. It requires an extra ~1% of main memory and cache memory width, and probably some extra pins on the processor.
Oracle enables this feature using surprisingly simple modifications to malloc(), so that adjacent objects (and objects re-allocated on top of freed objects) are always 64-byte aligned and always get a different 4-bit tag. User programs can write these memory tags. Of course, not every object will have its own tag (there are only 13 tags available) so a wild access has a 12-in-13 chance of faulting -- still vastly better odds than without this feature. This works even with old binaries, since they link with the new malloc. If the memory-tag-writing overhead is low enough, the compiler could also generate code in new programs to do the same thing with each stack frame (giving each frame (one or more) tags different from adjacent frames).
By contrast, old Burroughs system memory tagged each 48-bit memory word based on what kind of data it contained (for a small number of kinds defined specifically by hardware). E.g. all data words in all objects had tag 0, whereas array descriptors had tag 3. The tags were not checked against bits in the address used to access them, but instead against the type of instruction used to access them. User programs could not change these tags. This did not provide protection against pointers accessing data from outside their arrays, which is what the Sun/Oracle feature is designed to do. (That was done by a separate descriptor mechanism in Burroughs machines, unrelated to the tagged memory.)
The two most common elements in the universe are hydrogen and stupidity.
(Score: 0) by Anonymous Coward on Friday October 30 2015, @12:14PM
But couldn't the very same be achieved by simply allocating the memory in the virtual address space at an address with that bit pattern? Then if the upper four bits don't match, the pointer will simply point somewhere else, and if you arrange that this memory is unallocated (should be doable on the program or OS level), then the access will inevitably trap.
As a bonus, by doing it this way the exact bits (and even the number of bits) used for this could easily be different for each program, or even for each program run. Also, you'd need no specific hardware support except for the virtual memory management unit of the processor.