Meltdown Spectre SPARC Solaris?!?

In the last couple of weeks the whole IT was shocked getting news about security issues based on basic CPU architecture design covering “all” processor vendors… Spectre (CVE-2017-5753 and CVE-2017-5715) and Meltdown (CVE-2017-5754) vulnerabilities affected XEONs, AMD, POWER and ARM chips, but also SPARC uses similar features like all others. Spectre and Meltdown are different variants of the same fundamental underlying vulnerability, if exploited, allow attackers to get access to data previously considered completely protected. That affects chips manufactured in the last 20 years. Speculative execution to predict the future and out of order execution were implemented by Sun on their SPARC T3 chips (eg.: T3-1; GA November 2010, LOD September 2012).

@Meltdown;

Solaris never had kernel pages mapped in user context on SPARC. That’s the reason why I do not think Meltdown affects SPARC at all. Also Oracle mentioned “Oracle believes that Oracle Solaris versions running on SPARCv9 hardware are not impacted by the Meltdown”. But it could happen on Solaris x86 as far as I understood.

@Spectre;

Well, starting with T3 (S3 core) Oracle introduced speculative and out-of-order execution in the S3 pipeline. Prediction algorithms and deepness of the prediction buffers differs not only between vendors but across CPU generations. So it might be tricky but still possible to attack SPARC systems. Right now there is no public known attack for Solaris SPARC. Oracle says “Oracle believes that certain versions of Oracle Solaris on SPARCv9 are affected by the Spectre vulnerabilities.”

There are no public patches from Oracle at the moment to fix that issue, but an own MOS document for SPARC:

Oracle Support Document 2349278.1 (Oracle Solaris on SPARC and Spectre (CVE-2017-5753 and CVE-2017-5715) and Meltdown (CVE-2017-5754)) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2349278.1

All other Oracle products could be found at:

Oracle Support Document 2347948.1 (Addendum to the January 2018 CPU Advisory for Spectre and Meltdown) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2347948.1

Let’s see what will happen in the next days… stay tuned….

Console In/Output to ILOM

After a default Linux (in my case Oracle Linux 7.4) installation you won’t see anything after grub finished with “start /HOST/console”

Trick:

Worked on linux 7.4 running on Oracle Server X7-2

Spawn a TTY service on your serial console device port as a service:

# systemctl --now enable getty@ttyS0
Created symlink from /etc/systemd/system/getty.target.wants/getty@ttyS0.service to /usr/lib/systemd/system/getty@.service.

Another way is to tell grub2 to use the console... then you would also see booting and shutdown messages:

# grubby --remove-args="rhgb quiet" --args=console=ttyS0,9600 --update-kernel=ALL

Solaris Cluster Update

Had the fun today to upgrade a bunch of solaris clusters…. this time I wrote a docu 🙂

Cluster Update

let's update our cluster running a flying zone:

On both nodes:

 # scinstall -u update -b 11.3.26.0.5.0 -L accept 

[...]

disable the zone-resource

 # clrs disable name-zone-res 

reboot second cluster node where the RG is not running into the new BE after coming back, switch the RG to the updated node

 clrg switch -n <node> name-zone-rg 

Now set the BE UUID from the first node to the second

 first# /opt/SUNWsczone/sczbt/util/ha-solaris-zone-boot-env-id get
 second# /opt/SUNWsczone/sczbt/util/ha-solaris-zone-boot-env-id set <uuid>

Having the storage-res/RG on the second node and the right UUID you can attach the zone:

 # zoneadm -z <name> attach -x destroy-orphan-zbes 

Check if the zone comes up with a normal state (boot and svcs -xv). If ok, shutdown the zone again.

Now we can give the control back to the cluster

 # clrs enable name-zone-res
 # clrg resume name-zone-rg 

Now you can try to switch back...

And you could also upgrade your resource type version


# clrt list
SUNW.LogicalHostname:5
SUNW.SharedAddress:3
SUNW.HAStoragePlus:11
ORCL.ha-zone_sczbt:2
# clrt register ORCL.ha-zone_sczbt
# clrt register SUNW.HAStoragePlus
# clrt list
SUNW.LogicalHostname:5
SUNW.SharedAddress:3
SUNW.HAStoragePlus:11
ORCL.ha-zone_sczbt:2
ORCL.ha-zone_sczbt:4
SUNW.HAStoragePlus:12
# clrs list
pressy-zone-rs
pressy-zp-rs
# clrs show -p Type_version pressy-zone-rs
=== Resources ===
Resource:                                       pressy-zone-rs
  Type_version:                                    2
  --- Standard and extension properties ---
# /opt/SUNWsczone/sczbt/util/rt_upgrade +
Migration of resource:pressy-zone-rs to latest resource type version succeeded.
# clrs show -p Type_version pressy-zone-rs
=== Resources ===
Resource:                                       pressy-zone-rs
  Type_version:                                    4
  --- Standard and extension properties ---
#
# clrs show -p Type_version pressy-zp-rs
=== Resources ===
Resource:                                       pressy-zp-rs
  Type_version:                                    11
  --- Standard and extension properties ---
# clrs set -p Type_version=12 pressy-zp-rs
# clrt unregister SUNW.HAStoragePlus:11
# clrt unregister ORCL.ha-zone_sczbt:2
#

Oracle Solaris & SPARC @ OOW17

There were a lot of rumors about Solaris and SPARC because Oracle fired around 1.500 HW developers some months ago. Around Oracle Open World were some product announcements and more information about Solaris. A brand-new SPARC chip came out and Oracle promised once again to invest into Solaris and give a Solaris 11 support at least until 2034.

They also mentioned the next Solaris 11.next release will come in fall 2017. So it will take some time to get 11.4 but hopefully with the  backport of Solaris 12 beta features since they canceled 12 in favor of 11.next.

Oracle SPARC M8 Processor

The new SPARC CPU has 32 cores again but at 5 GHz based on a new 20nm core design with “Software in Silicon v2”.  We have now four execution pipelines, they doubled the size of L1 cache and increased the performance of the DAX engines (1.8 vs. 2.2 GHz). M8 comes with 180 GB/s memory bandwidth measured, and a raw memory links performance of 374 GB/s per processor. (BTW; did you know that the latest Xeon 8180M launched at Q3’17 only provides 119 GB/s). We got Oracle number acceleration units and SHA-3 was added to the other 15 cyphers and hashes we had in M7 cryptography co-processors.

Compared to M7 that is a 1.5x better single-thread performance with 21% higher frequency and on the memory site 16% higher bandwidth but with still 6% lower memory latency. That’s a very nice and easy improvement for your Solaris installations. And do not forget, just migrate your LDOM live to the new M8 server and enjoy the faster environment…

Oracle says:

SPARC M8 processors running Oracle Solaris 11.3 ran 2.9 times faster executing AES-CFB 256-bit key encryption (in cache) than the Intel Xeon Processor Platinum 8168 (with AES-NI) running Oracle Linux 7.3.

SPARC M8 processors running Oracle Solaris 11.3 ran 6.4 times faster executing AES-CFB 256-bit key encryption (in cache) than the Intel Xeon Processor E5-2699 v4 (with AES-NI) running Oracle Linux 7.2

Oracle Fujitsu SPARC XII

Also Fujitsu announced a new Sparc64 processor called SPARC XII which can be bought as OEM from Oracle. A 12 core CPU @ 4,25 GHz in systems with 1 to 32 sockets and up to 32 TB memory.

 

 

Oracle X7 Server

With the latest x86 generation you will also get Support and the RTU for Solaris-x86. Oracle X7 Server comes with 1 up to 8 Sockets with 192 cores and 6 TB memory.

Overall great news for your Solaris investments and big datacenter irons 🙂

 

 

 

Solaris FMD logs

How to clear fmadm log or FMA faults log

(based on FMA Cheat Sheet (Doc ID 1355350.1))

Had some issues in the last days getting my "fmadm faulty" empty... standard commands did not work

# fmadm repair <UUID>
# fmadm clear <UUID>
# fmadm acquit <UUID>

I had to delete FMDs "database" files:

# svcadm disable -s svc:/system/fmd:default
# cd /var/fm/fmd
# find /var/fm/fmd -type f -exec ls {} \;
# find /var/fm/fmd -type f -exec rm {} \;
# svcadm enable svc:/system/fmd:default
# fmadm reset cpumem-diagnosis
# fmadm reset cpumem-retire
# fmadm reset eft
# fmadm reset io-retire
# fmadm faulty
<empty output again>