By Parnian Taidi-Oracle on Feb 11, 2016
In an earlier blog we talked about Solaris /SPARC features that enable you to increase end-to end security of your applications. One of the key security risk areas in applications is memory corruption.
Applications are vulnerable to memory corruption due to both
common software programming errors as well as malicious attacks that exploit
software errors. 317 million new malicious programs and 24 zero-day vulnerabilities were reported in 2014 alone*.
Memory corruption causes unpredictable application behavior and system crashes. A victim thread encounters incorrect data sometime after the run-time error occurred making these bugs extremely hard to locate and fix. Buffer overflows are a major source of security exploits. In-memory databases increase this exposure as terabytes of critical data reside in-memory. Databases and Operating Systems have tens of millions of lines of code, developed by distributed teams of thousands of developers, so errors introduced by a subsystem could adversely affect one or more other subsystems.
Oracle Silicon Secured Memory (SSM) is a feature of Oracle SPARC T7/M7 systems that detects invalid data accesses based on memory tagging. A version number is stored by software in spare bits of memory. Dedicated non-privileged load/store instructions provide the ability to assign a 4-bit version to each 64-byte cache line. Metadata stored in memory is maintained throughout the Cache hierarchy and all Interconnects. On load/store operations, the processor compares the version set in the pointer with the version assigned in the target memory and generates an exception if there is a mismatch.
3 hours vs 1 minute
SAS recently completed a proof of concept using SSM with SAS 9.4 and the Oracle Studio Discover tool.
SAS 9.4 is a large memory intensive enterprise application predominantly written in C. Using a standard debug track that uses malloc(3) for memory allocation, SAS test programs could be run by optionally interposing the Oracle Studio discover ADI shared library to intercept malloc() calls. This transparently enables discover ADI to utilize SPARC M7 Silicon Secured Memory to check for memory corruptions at the silicon layer and produce full stack walk backs if a memory corruption was found.
They were able to realize the following immediate results:
– Tag Cross platform bugs in just 2-3 days of testing
– Find, triage, fix and put back bugs in less than 2 hours
– Identify bugs 180x faster
• Other memory validation tool: 3 hours
• Silicon Secured Memory and Discover tool: 1 minute
Memory Validation Testing In QA Cycles
SSM along with the Oracle Studio discover ADI allows ISVs to perform full QA runs running them at near real time speed, whereas traditional memory validation tools cannot be used as such due to their high performance overhead and instead are typically only used to debug memory corruptions after bug reports come in.
If you develop or deploy large scale memory intensive applications, can you afford not knowing how SSM can help you with your products quality and security?
For more on the SAS as well as the Oracle Database experience with SSM, see the OOW 2015 presentation CON8216: “Inoculating Software, Boosting Quality: Oracle DB & SAS Experience with Silicon Secured Memory” (PDF).
To learn more about SSM and how your applications can take advantage of it, read the article Detecting Memory Errors with Silicon Secured Memory.