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
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
memory validation tool: 3 hours
Secured Memory and Discover tool: 1
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
To learn more about SSM and how your applications can
take advantage of it, read the article Detecting
Memory Errors with Silicon Secured Memory.
on the April 2015 Internet Security Threat Report from Symantec.