Tuesday, November 13, 2018

DoD: 5-10 Year SPARC Processor Contract Award

[SPARC M8 Processor, Courtesy Oracle Corporation]

DoD: 5-10 Year SPARC Processor Contract Award


The SPARC family of processors had been produced by manufacturers, both foreign and domestic, for decades. Sun Microsystems created the first SPARC specification, with dozens of manufacturers creating their own implementations. Vendors such as Fujitsu and Oracle continue to produce SPARC processors, today. Vendors have been providing On-Premise to Off-Premise compute power in recent years. The Department of Defense had awarded another contract, SPARC support for 5-10 years to ViON, who provides both on and off premise SPARC compute resources.
[SPARC Logo, courtesy SPARC International]

SPARC Introduction:

The SPARC Processor was created to out scale older processor chips in the 1980's, becoming one of the most successful 32 bit commercial RISC processors. The first 64 bit SPARC processors were released in 1993, a decade before Intel processor clone manufacture AMD created an x86 64 bit processor using AMD64 in 2003, with Sun porting Solaris. Intel followed a year later with Intel64 in 2004, a full decade after Sun had released 64 Bit SPARC. SPARC continued to be the fastest single thread, largest memory footprint, or largest scalable SMP multiple threaded workhorse in the industry, for decades to come... with CPU chips supplied from various vendors.
[Oracle SPARC M8 Processor Addition in 2017, courtesy Oracle Corporation]

Today's SPARC:

SPARC continues to be the fastest single thread, single core, single, socket, and SMP multiple socket performer, on the market today... with many additional features such as database accelerators, cryptographic accelerators, and decompression accelerators. The need for the fastest processing continues to be needed by high end customers, such as government, defense, and large enterprises.
[Fujitsu/Oracle SPARC M12 Chassis, courtesy Fujitsu]

Fujitsu's M12 Processor

Fujitsu's latest April 2017 implementation of SPARC is the M12 processor, with 12 cores per socket, 8 threads [vCPU] per core, more co-processors, and ability to expand to 32 sockets in a pair of racks. This allows for massive compute & memory capacity on a scale unachievable in in other architecture platforms. Platforms such as this is optimal for massive Government and Multi-Nation Enterprises.


[Oracle SPARC M8 Block Diagram, courtesy Oracle Corporation]

Oracle M8 Processor

Oracle's latest August 2017 implementation of SPARC is the M8 processor, with 32 compute cores, 8 threads [vCPU] per core, more co-processors, phenomenal performance outrunning all non-SPARC processors [as has been consistent, for years.] Oracle implemented 8 Sockets per chassis, to meet their own Enterprise based Engineered System requirements.


[SPARC Physical and Logical Virtualization, courtesy Oracle Corporation]

SPARC Virtualization:

Before other mainstream vendors had built some degree of virtualization, a mature 64 bit SPARC platform offered many options of virtualization, adding various layers over time:
  • Physical Domains (1993 by the Cray Superserver 6400)
  • Zones [Containers] (2004 by Sun Microsystems on Solaris 10 Beta Build 51)
  • Logical Domains (2007 by Sun Microsystems on their SPARC T1 processors)
Vendors like ViON can technically provide compute resources via any one of these technologies, including bare-metal physical.


SPARC and the Solaris Operating System, which provides amazing flexibility to larger installations. It appears that this latest government contract will last well into the next SPARC release, projected by both Oracle & Fujitsu - where both vendors expect the next SPARC release to be 2020.

Tuesday, October 30, 2018

Solaris 11.3 SRU 35 - The Last SRU; Solaris 11.4 Lives!

Solaris 11.3 SRU 35 - The Last SRU; Solaris 11.4 Lives!

The Solaris 11.3 SRU 35 is the final SRU for Solaris 11.3. This SRU seems to have an issue with breaking OpsCenter agents and proxies. There does not seem to be very good reason to upgrade to this SRU, since it does more damage than benefit.

Solaris 11 is officially moved GA [2018-08-25] to 11.4! Oracle released SRU 1 [2018-09-24] and SRU 2 [2018-10-16] in rapid succession. have been released, but OpsCenter is sill broken.

Solaris 11 is now on a monthly SRU train and a yearly minor release train. Each month will be a new SRU. Summer of 2019 will be Solaris 11.5


The defect appears to be a problem with an OS bundled release of Java. No official release of Ops Center is planned to be released, to correct this problem. OS mitigations and interim patches for OpsCenter leave a bad taste in this author's mouth. Oracle needs to make an official release of OpsCenter or fix Java.

Monday, October 29, 2018

Oracle Linux on SPARC is dead? Oracle Linux at Risk?

Oracle Linux on SPARC is dead? Oracle Linux at Risk?

Oracle made substantial changes in their strategy last year, perhaps on a "Wim"... and now they seemed to bet wrong.

Oracle has long pinned some of it's engineered systems on a clone of Red Hat Linux. After purchasing Sun, they released storage servers based upon Solaris on Intel and left it's other engineered systems on their knock-off Linux OS. 

Oracle had to suffer through the successive Intel CPU fixes making each successive patch release slower or less secure. Now, the dominate Linux Vendor [Red Hat] that Oracle had been copying is being purchased by IBM. 

[SPARC logo, courtesy SPARC International]


It appears that there is still a SPARC of life in the world's highest performing CPU architecture... and that life in Solaris. There has been a recent roadmap release [ie 2018-08] which is substantially the same as it's previous release some 5 months earlier.

[Oracle logo, courtesy Oracle Corporation]

Oracle SPARC

Oracle releases a new roadmap with an M8+ chip coming (ie 2018-03) and continues to design Oracle Solaris, for the distant future, for over a decade.

Oracle SPARC Solaris appears to be a steady ship, in turbulent seas.

[Fujitsu logo, courtest Fujitsu corporation]

Fujitsu SPARC

This seems to coincides with the Fujitsu roadmap [i.e. since last year!] It seems Fujitsu is designing the silicon for Oracle as they advance the Solaris Software layer. Fujitsu, a hardware provider supplying SPARC chips for Sun when SPARC was first created, continues to talk about new product coming [in 2018-02-03, 2018-03-15] - which is good news!

Fujitsu leaked [in 2018-07-06] is getting closer to releasing it's new Supercomputer architecture, not based upon SPARC, which probably means Fujitsu's Linux for SPARC will soon have no future.

Oracle Linux

There has been some speculation about Linux on SPARC from NetMgt. The last update of Oracle Linux on SPARC looks like Summer 2017. It appears to have stalled, possibly killed when Wim returned to the Oracle in November 2017.

Oracle's knock-off Linux is based  upon Red Hat Linux... which is now being purchased [in 2018-10-28] by arch-enemy competitor IBM... who competes in all Oracle's major spaces (i.e. Cloud, RISC servers, Intel Servers, Database, etc.)


NetMgt has been tracking Oracle Linux for some time, but it appears Oracle Linux on SPARC stalled last year. Oracle Linux on SPARC now appears dead on arrival. Fujitsu SPARC no longer has a need for Linux. Oracle's Linux, is now oddly in a strange risk place, under Intel whose CPU's get slower with every defect fix. Oracle SPARC Solaris continues to be the highest performing Vendor Architecture and OS combination - the "sun" continued to shine in the darkness of declining performance of competitors.

Tuesday, August 14, 2018

SPARC Immune: L1TF vulnerabilities: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646

SPARC Immune: L1TF vulnerabilities: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646


Intel has been hit repeatedly by massive numbers of CPU bugs, affecting everything from tablets, to laptops, to desktops, to servers. The latest is called L1TF, and SPARC is immune.


Oracle describes a set of vulnerabilities in the Intel processors.

These L1 Terminal Fault (L1TF) vulnerabilities affect a number of Intel processors, and they have received three CVE identifiers:
  • CVE-2018-3615 impacts Intel Software Guard Extensions (SGX) and has a CVSS Base Score of 7.9.
  • CVE-2018-3620 impacts operating systems and System Management Mode (SMM) running on Intel processors and has a CVSS Base Score of 7.1.
  • CVE-2018-3646 impacts virtualization software and Virtual Machine Monitors (VMM) running on Intel processors and has a CVSS Base Score of 7.1
Once again, SPARC is immune.


As life continues in the world of telecommunications & data center, there is still one safe choice for high performing systems: SPARC.

Friday, July 13, 2018

Solaris 11.4: KSplice Arriving

[Solaris Logo, Courtesy Sun Microsystems]

Solaris 11.4: KSplice Arriving!


The concept of patching an OS system has existed since the beginning of computers. At one time, source code needed to be compiled and a system rebooted with the new OS. Pre-compiled patches were later shipped by OS vendors. Patches were often allowed to be applied while the OS in Single User Mode. Sun had created the concept of Live Upgrade, where patching could be done to an alternate boot environment & booted at later convenient time, to reduce downtime to a simple reboot. In 2007, another feature referred to as Deferred Activation Patching allowed for the current running Sun Solaris 10 OS to be patched, while deferring some of the patches until the next boot, leveraging loopback file systems. In 2008, KSplice concept was birthed from MIT for LINUX kernels, to perform some degree of patching, while severely limiting reboots. Oracle purchased Sun and Solaris in 2009. The MIT students won a $100K award, to start up a company in 2009. KSplice was  purchased by Oracle in 2011. The promise of KSplice and rebootless patching for Solaris was understood in concept, but not executed, until recently.

[Oracle Logo, courtesy, Oracle Corporation]

The Road to Solaris:

KSplice team had talked about Solaris support, before the purchase by Oracle, but it was first being integrated into Linux Platinum Support. NetMgt discussed the benefits & differences in KSplice for Linux vs Solaris in 2012. NetMgt reported that Solaris and KSplice Engineers were meeting in 2012. Goals included:
  1. Solaris team bringing KSplice technology into OS
  2. Reboot-less small fixes via KSplice into Solaris
  3. Allow customer to keep patches "up to date" with year long uptime
  4. Leverage Synergies with existing philosophies:
    (DTrace allows data path switching without latency or interruption)
The engineering task of merging DTrace & KSplice technologies between Linux & Solaris was seemingly on. In 2015, NetMgt reported discussion of KSplice for Platinum Support Linux with DTrace became a major differentiator for Oracle, but KSplice discussion regarding Solaris was still dark... until 2018.

[Solaris 11.4 Beta image, courtesy Oracle Corporation]

Solaris 11.4 (aka Solaris 12)

Since KSplice was a significant feature, those of us in the industry expected it to arrive in Solaris 12. To casual observers, it became clear that "big bang" approach to OS's was becoming obsolete. Apple started delivering MacOSX, continually, with no major interruptions. Windows started delivering Windows 10 continually, with no major future interruptions planned. Solaris announced they would be entering a similar Continuous Delivery model in 2017. Some reporters spread #FakeNews about Solaris being dead, but those who understood industry trends were watching for features from Solaris 12 to be integrated. The first & second Open Beta release of Solaris 11.4 was done... and it was clear that Solaris 12 features were being bundled into the Solaris 11 stream, but KSplice was conspicuously missing.

KSplice Hints

We started seeing hints of KSplice in 2017. The test cases for spliceadm were now being bundled. Many thanks to Tim Foster, to providing a hint into the future!

KSplice Infrastructure

It seems the infrastructure for KSplice was bundled in Solaris 11.4, but live splices have not been made publicly available. A sample of what we can observe from the manual.


The use of the "adm" suffix in commands for administration has become quite well known in Solaris. A new such command magically appeared in the 11.4 - "spliceadm". The manual page says "Splices are fixes for specific bugs that can be applied on a live system" - KSplice arrived! The Interface Stability is declared as "Committed" - it is here to stay!

Freeze and Unfreeze

A new concept was introduced to KSplice in Solaris 10 - freezing. This seems to be a way to allow for automatic updates, limit automatic updates to a particular splice version, or even facilitate rollbacks to a lower numerical splice. This facilitates the downloading of splices to a system, yet restriction of splice activation/rollback until a time of low utilization.

[Former KSplice Team, courtesy MIT News]

The Back Story

A former engineer, Enrico, from Sun/Oracle published the back-story on KSplice for Oracle Solaris. It appears he had worked with Tim [Foster, perhaps?] on the project. He spoke of resolving scaling problems, not experienced under Linux, due to huge stack sizes supported by SPARC Solaris systems while running latency sensitive Oracle Cluster. He also spoke of KSplice & DTrace compatibility - which we discussed earlier in this article with Linux.

Special thanks for those Enrico identified: Jan Setje-Eilers, Scott Michael, Kuriakose Kuruvilla, Pete Dennis, Rod Evans, Ali Bahrami, Mark J Nelson, Xinliang Li,Raja Tummalapalli, Albert White, Adam Paul, and Gabriel Carrillo.


As an Application Architect in Remote Network & Systems Management, Configuration Management, and Incident Management - I had personally developed & used techniques to deploy code live in arenas where continual uptime was required. It is good to see similar techniques reach into the OS arena.

Sun had previously set a very high bar with Solaris, offering the ability to patch a live system with complete patch application on a reboot, or applying many parts of a system (until eventual reboot.) Some of this flexibility was rolled back with Solaris 11, to see KSplice finally start arriving on the scene with Oracle Solaris 11.4.

While Oracle Solaris is not rolling splices yet, we look forward to 100% uptime with KSplice, in conjunction with using LDom's on SPARC hardware.

Wednesday, May 23, 2018

Spectre - SPARC Solaris: The Safe Choice

Spectre - SPARC Solaris: The Safe Choice


As the industry continues to struggle with Meltdown, a second vulnerability family appeared referred to as Spectre. As of this article publication, there are 4 variants of Spectre, the latter two variants referred to as Spectre-NG. All SPARC systems are safe, if the most recent systems are on the most current firmware & OS releases. As of this publishing, the latest application/OS & firmware patches fixes the first two. The later 2 does not affect SPARC, as the rest of the Intel and other CPU communities are struggling with their cloud and local server infrastructures.
[Spectre logo, courtesy solaris.wtf]


Spectre comes in 4 variants, the first 2 and next 2 identified as of the publishing of this article.

Spectre v1

Upgrade firefox to 57.0.4 or greater for protection (i.e. bundled in recent Solaris 11.3 updates.

Unpatched super-scalar CPU's (i.e. SPARC T4, T5, M6, M7, S7, M8, M10, M12) could possibly be exploited by CVE-2017-5753.

Spectre  v2

 A quick summary on Stack Exchange on how Spectre works:
the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result (if -> true), that results in asking for an out-of-bound memory access that the victim process would not normally have requested, resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way, memory belonging to the victim process is leaked to the malicious process.
Unpatched super-scalar CPU's (i.e. SPARC T4, T5, M6, M7, S7, M8, M10, M12) may be exploited by CVE-2017-5715.

Spectre v3a

All 64 bit SPARC is immune to CVE-2018-3640 .

Spectre v4

All 64 bit SPARC is immune to CVE-2018-3639 .

[SPARC Logo, courtesy SPARC International]


Modern 64 bit SPARC variants come in 2 classes: Scalar and Super-Scalar
[Sun Microsystems Logo, courtesy Sun Microsystems]

Sun UltraSPARC

Older Sun UltraSPARC 64 bit Servers do not have the CPU feature which could possibly be exploited and were not vulnerable... they did not issue speculative instructions. Oracle had purchased Sun, so their support channel can provide a definitive explanation. Performance was mostly driven on these servers leveraging SMP chassis, Multi-Core sockets, and large memory footprints.
[Oracle Logo, courtesy Oracle Corporation]

Oracle SPARC

Newer Oracle SPARC Solaris servers are possibly vulnerable, if you are running a modern CPU which initiates speculative instructions (i.e. T4 or newer) while older 64 bit CPU's are not vulnerable. It has been reported on Solaris WTF that "Spectre (CVE-2017-5753 and CVE-2017-5715)" has been fixed in firmware (i.e. T4: 8.9.10 or greater; T5, M5, M6: 9.6.22a or greater; M7, S7, M8: 9.8.5c or greater.)

The short story, a firmware patch for CPU's newer than T4 are required and the impact is very minor in performance, according to the previous blog. Stock Firefox as shipped with Solaris 10 is vulnerable to Spectre v1, Solaris 11 fixed Firefox vulnerability early 2018, so users should migrate to Solaris 11.

[Fujitsu Logo, courtesy Fujitsu corporation]

Fujitsu SPARC

Sun and Oracle are not the only 2 vendors, who have produced 64 bit SPARC platforms. Newer Fujitsu SPARC Servers are also super-scalar, possibly vulnerable to Spectre v2 (CVE-2017-5753), and have been been fixed in firmware (i.e. M10: XCP2351; M12: XCP3051.)


If you are using an older Sun UltraSPARC server, you are OK. If you are running a newer Oracle SPARC (i.e. T4 or newer) server, you should update Firefox on Solaris 10 or get on the latest Solaris 11 release to be protected from Spectre v1. For the same class of hardware, apply firmware patches available today to protect from Spectre v2. SPARC is immune to Spectre v3 & v4. Get with your Oracle support for the first 2 variants (doc id 2349278.1) and second 2 variants.

Friday, May 18, 2018

Meltdown - SPARC Solaris: The Only Safe Choice

Meltdown - SPARC Solaris: The Only Safe Choice


As the rest of the industry has been struggling with security vulnerabilities, SPARC Solaris platforms have been relatively quiet. Meltdown, otherwise known as CVE-2017-5754, has taken the world by storm. Operating Systems have long relied on Memory Management Units to isolate user application programs from the OS kernel. This had come to a screeching halt, leaving lesser secure systems in a world of hurt.

[Meltdown Logo, courtesy solaris.wtf]

Meltdown Vulnerability:

Some OS's will keep the Kernel Pages mapped into the same context as User Application Pages. This is often done for speed (i.e. linux) but places extra dependencies upon the MMU for isolation. Nearly all OS's had ceded this security concern to the CPU vendor, instead of applying the most secure practice in the OS architecture.


As one vendor noted, SPARC Solaris is immune from Meltdown and about the only platform not subject to this critical vulnerability in the data center. This was accomplished by OS designers placing Kernel and User pages into different contexts, a design which added additional security, but at a performance cost that other OS designers in the industry were not willing to cede.


Some Solaris systems, decades ago, may be affected, but nothing modern. Secure by Design is a typical decision for Solaris architects, a decision that has served them well for the decades they served a 64 bit OS to the user community, as other OS vendors played "catch up" in performance or features or functionality.