Tuesday, November 13, 2018
Tuesday, October 30, 2018
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
Conclusions: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 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 SPARCOracle 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 SPARCThis 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 LinuxThere 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.)
ConclusionsNetMgt 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
Abstract: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.
Description: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
Conclusion: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 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:
- Solaris team bringing KSplice technology into OS
- Reboot-less small fixes via KSplice into Solaris
- Allow customer to keep patches "up to date" with year long uptime
- Leverage Synergies with existing philosophies:
(DTrace allows data path switching without latency or interruption)
|[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 HintsWe 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 InfrastructureIt 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.
SpliceAdmThe 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 UnfreezeA 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 StoryA 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.
Conclusions: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
Abstract: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.
Upgrade firefox to 57.0.4 or greater for protection (i.e. bundled in recent Solaris 11.3 updates.
Spectre v2A 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 v3aAll 64 bit SPARC is immune to CVE-2018-3640 .
Spectre v4All 64 bit SPARC is immune to CVE-2018-3639 .
|[SPARC Logo, courtesy SPARC International]|
SPARCModern 64 bit SPARC variants come in 2 classes: Scalar and Super-Scalar
|[Sun Microsystems Logo, courtesy Sun Microsystems]|
Sun UltraSPARCOlder 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 SPARCNewer 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]|
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.)
Conclusions: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
Abstract: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]|