Analysis 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.
Where we've come from
Rewind to September last year, and you may recall Ellison bragging about what he said was "the most important thing we've done in silicon, maybe ever." Back then we knew that 32-core M7 packages would be destined for machines juggling thousands of threads with terabytes of RAM. Big heavy boxes with big heavy price tags.
Then in August this year, Oracle's engineers revealed Sonoma: a system-on-chip that uses the M7 blueprints with InfiniBand interfaces and directly accessed RAM bolted on.
Stopping the exploitation of security vulnerabilities
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.
So imagine a classic use-after-
free() scenario: there's a pointer to a block of memory, and they both share the same version number. That area of memory is freed, and soon after it is reallocated to another part of the program with a new version number. If the original pointer is used to access the block, the version numbers won't match, and the program is stopped.
Using pointers to data after they have been freed is the cornerstone of pretty much all major Adobe Flash and Internet Explorer exploits, allowing miscreants to manipulate data structures to hijack the running thread.
The programming blunders that allow this abuse to happen can also blight server applications: exploitable use-after-
free() bugs can lie in code running in your data center.
Now imagine a pointer to a block of memory that's 8000 bytes in size, and the application tries to access a 64-bit word 16000 bytes from the start of the pointer – way, way outside the allocated space. Assuming the access avoids a guard page and still falls in allocated memory, and thus doesn't trigger a page fault, the version number of the pointer won't match the version number of the block of memory it has trespassed in, which will trigger an exception and stop the program.
Now take all of the above, and replace version numbers with colors, and you've got Ellison's presentation on Tuesday afternoon at OpenWorld in San Francisco:
On the M7, pointers and their memory blocks are stamped with a 4-bit "color", and accesses are verified to make sure the color in the highest bits of the pointer matches the color of the memory allocation. This works with virtual memory allocated from the heap rather from the stack, it appears. Solaris tries to avoid giving adjacent blocks the same color.
(If you really want to get down to the weeds: the color is stored with each 64-byte cache line in memory. Whenever the CPU accesses RAM, it slurps in a cache line at a time. The color stored with each cache line is used to check pointer accesses within that 64-byte block.)
Er, just four bits?
Four bits of color means there are 24, or 16, possible colors a memory block can have. A hijacked pointer has a one-in-16 chance of having a matching color when it accesses a block of memory, allowing it to circumvent the SSM defense mechanism. Those are pretty good odds, certainly odds a seasoned hacker will take.
If an attacker decides to take her chances, launches an exploit against an app vulnerability, hits a mismatched pointer-block color pairing, and triggers a crash under SSM, the failure may make enough noise to trip security alarms and wake up competent sysadmins to the intrusion attempt.
If it doesn't alert anyone, and after enough attempts she manages to hit matching pointer-block colors in her exploit, she'll be able to force her way inside the vulnerable application and face off any other defenses that may await her, such as ASLR.
It is even possible she can alter the color bits in a pointer to match the color of a block she wishes to access, and thus avoid any crashes and detection.
In short, SSM is a mitigation rather than bulletproof protection.
"We're pushing security down into the silicon. This gets us ahead of the bad guys," Ellison told his audience.
"SSM would have discovered Heartbleed, and stopped it in real time. It would have discovered Venom, and shut down Venom in real time. It's deceptively simple – why didn't we do this before? Good question."
Tagged memory is not a new concept in computer science. For example, the lowRISC open-source system-on-chip project, which builds on the RISC-V processor architecture, has a similar memory-tagging mechanism. This Oracle blog post has more info on SSM, which is the new name for ADI. You can see the color bits in pointers in this example code.
Speeds and feeds and other features
We're told the microprocessor includes hardware accelerated implementations of the AES, Camellia, CRC32c, DES, 3DES, DH, DSA, ECC, MD5, RSA, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 crypto algorithms, and coprocessors to accelerate the inner plumbing of SQL queries – such as "memory de-compression, memory scan, range scan, filtering, and join assist." This means Oracle Database running on the M7 can offload parts of queries to the silicon to perform in the background while the cores run more code.
Oracle reckons its M7 has broken "world record results in over 20 benchmarks." The M7 is a 4.13GHz 32-core, 256-hardware-thread CPU with 64MB of on-chip L3 cache. It can scale up to 512 cores and 4,096 threads, and address up to 8TB of physical RAM. The CPU architecture is Sparc V9.
The chips will power a family of new servers:
- SPARC T7-1 [datasheet PDF] 32-core 4.1GHz M7 CPU, up to 512GB of RAM, four 10GbE ports, up to eight 600GB or 1200GB 2.5in SAS-3 drives, or up to eight 400GB SSDs or four 1.6TB NVMe drives. Oracle Solaris 11.3 or later recommended.
- SPARC T7-2 [datasheet PDF] Two 32-core 4.1GHz M7 CPUs, up to 1TB of RAM, four 10GbE ports, up to six 600GB or 1200GB 2.5in SAS-3 drives, or up to six 400GB SSDs or four 1.6TB NVMe drives. Oracle Solaris 11.3 or later recommended.
- SPARC T7-4 [datasheet PDF] Two or four 32-core 4.1GHz M7 CPUs, up to 2TB of RAM, four 10GbE ports, up to eight 600GB or 1200GB 2.5in SAS-3 drives, or up to eight 400GB SSDs or eight 1.6TB NVMe drives. Oracle Solaris 11.3 or later recommended.
- SPARC M7-8 [datasheet PDF] Two to eight 32-core 4.1GHz M7 CPUs, up to 4TB of RAM, up to 24 low-profile PCIe 3.0 (x16) slots. Oracle Solaris 11.3 or later recommended.
- SPARC M7-16 [datasheet PDF] Four to 16 32-core 4.1GHz M7 CPUs, up to 8TB of RAM, up to 48 low-profile PCIe 3.0 (x16) slots. Oracle Solaris 11.3 or later recommended.
- SuperCluster M7 [datasheet PDF] Lots of configurations for this beast.
For availability, give your Oracle rep a call.
Finally, if you want more insight into the world of Oracle and its plan for cloud, check out our sister site The Platform, and this analysis by co-editor Timothy Prickett Morgan. ®