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: 2) by NCommander on Friday October 30 2015, @02:36PM
Personally, using the top bits of a pointer is asking for trouble. There are far better ways to solve the problem Old Mac users may remember the pain caused when the platform went from 24-bit pointers to 32-bits. Anything that used the top part of the pointer promptly broke. In terms of portability, hile x86_64 implementations generally only allow for the use for 48-bits of the address space, that's not true for all 64-bit platforms, as well as which parts of the 64-bit address space they use or don't use diff.
Frankly, the way to fix this is not having a linear memory map; x86_16 (aka real mode) required code and data to be separated into different segments, pointed at by CS and DS. Anything in a data segment could not be executed by the processor (it would caused a fault if I remember behaviors correctly). Unfortunately, C requires a flat memory map to be usable (for anyone who did 16 bit real mode programming, you'll remember the pain of near and far pointers). Strictly speaking, you could also use segmented mode in 32-bit Protected Mode by loading a GDT that separated the data and code regions of memory, though the only thing that I can think that used it was paravirtualization with Xen, and possible some 286 protected mode programs. 64-bit Long mode got rid of segmenting almost entirely (rfx and rgx still exit to help with thread local data).
Assuming a segmented memory system, you simply have a segment for each item on the heap, with its specific size encoded*; if you overread the segment, you generate a fault. There's no *great* way to do this with a flat memory model without fragmenting memory and making paging much more complicated.
With a flat memory map, you have to kludge around it in other ways; OpenBSD has W^X for instance, or the NX-bit on the MMU, which helps, but isn't perfect; heartbleed happened because it effectively had "exploit mitigation countermeasures" to quote the BSD devs.
* - x86_16 only supported a fixed size of 64 KiB. 32-bit segmenting on x86_32 appears to support variable sizes as part of the ldt, but don't quote me on that; I don't feel like digging out the reference manual to check.
Still always moving
(Score: 0) by Anonymous Coward on Friday October 30 2015, @02:39PM
x86 real mode didn't have any memory protection. You are probably thinking of 16 bit protected mode (guess where that name came from).