(なお、Intel以外にもAMDとARMのCPUも対象となるSpectre(CVE-2017-5715,CVE-2017-5753)は未修正です。当初はこれについても適用されているのかと思っていましたが、確認したところこれは勘違いでした。今後改めてアップデートされる予定とのことです)
本件修正により、3割程度の性能低下が見込まれるものと見積もられている事もさる事ながら、本件で問題になっているような、通常変更が想定すらされていないコア部分の修正ですから、不具合を警戒して数日様子見をしたのですが、とりあえず私の環境下では性能低下以外の深刻な問題は発生していないようなので適用に踏み切ってみた次第です。勿論ロールバックのパスは確保した上で。
と言っても、いきなりメインの系列に入れるのは怖いので、サブ系のPC数台で試してみました。OSは全てLinuxで、そのうち2台がUbuntu17.10、1台がUbuntu16.04LTSです。CPUは、C2D世代、SandyBridge世代、Haswell世代が各1台です。
まず動作自体は特に問題は見られませんでした。いきなり落ちたり固まったりはしない、という意味です。そうでないと困るのですが、修正の内容が内容ですからね。実際WindowsではAMDの旧CPUについて深刻な副作用があったらしいですし。とそれはともかく。
で、問題の性能低下の件ですが、概ね3台とも同様の傾向を示しました。全て掲載するのも無駄が大きそうなので、とりあえず中間のSandy世代のCPU(G630)を積んだPCの分のベンチマーク結果を下記に掲載します。ベンチマークに用いたソフトは以前にも使った事のあるunixbench(5.1.3)で、シングルタスク(1-way)とマルチタスク(2-way)それぞれ、各項目について適用後(after)と適用前(before)及びその比を一覧表にしています。
結論から言えば、前評判そのままの酷さでした。総合スコアで見れば、シングルで27%、マルチで24%のダウンです。3割程度という事前情報に偽りなしですね。
個々に見ると、整数や浮動小数点等のコア内部で完結する処理については影響は無いのは当然として、やはりカーネルとのやり取りが発生する処理では大幅な落ち込みが見られます。
個別の項目で言えば、ファイルI/Oで1割から4割、またプロセス生成やシェルスクリプト全体について1割前後の減少。これだけでも、バッチ処理のスケジュールとか色々冷や汗が出る感じですが、まだこれはマシな方です。
特に悪いのは、パイプ処理とシステムコールです。パイプのスループットはおよそ5割にまで落ちていますし、システムコールのオーバーヘッドに至っては7割超の減少、すなわち1/4前後にまでパフォーマンスが落ちています。これはもう壊滅的と言っていいでしょう。
要するに、プロセス間通信だとか、ファイル関連の処理だとか、メモリの操作だとかが超絶遅くなる、という事です。それらの処理を多用する処理の代表たるデータベース系の性能が著しく低下する、というのも当然の結果と言うべきでしょう。
1-way(シングル) | after | before | after/before |
Dhrystone 2 using register variables | 2706.2 | 2706 | 1.00 |
Double-Precision Whetstone | 666.4 | 666.3 | 1.00 |
Execl Throughput | 898.9 | 1015.4 | 0.89 |
File Copy 1024 bufsize 2000 maxblocks | 1452.3 | 2190.2 | 0.66 |
File Copy 256 bufsize 500 maxblocks | 980.9 | 1667.2 | 0.59 |
File Copy 4096 bufsize 8000 maxblocks | 2796.9 | 3638.1 | 0.77 |
Pipe Throughput | 789.1 | 1544.4 | 0.51 |
Pipe-based Context Switching | 428.9 | 482.8 | 0.89 |
Process Creation | 925.4 | 1060.1 | 0.87 |
Shell Scripts (1 concurrent) | 2313.1 | 2470.2 | 0.94 |
Shell Scripts (8 concurrent) | 3028.5 | 3235.4 | 0.94 |
System Call Overhead | 553.1 | 2369.4 | 0.23 |
System Benchmarks Index Score | 1187.2 | 1634.7 | 0.73 |
2-way(マルチ) | after | before | after/before |
Dhrystone 2 using register variables | 5398.8 | 5408.7 | 1.00 |
Double-Precision Whetstone | 1329 | 1331.3 | 1.00 |
Execl Throughput | 1965.7 | 2213 | 0.89 |
File Copy 1024 bufsize 2000 maxblocks | 2639.1 | 3031.2 | 0.87 |
File Copy 256 bufsize 500 maxblocks | 1832.3 | 1990 | 0.92 |
File Copy 4096 bufsize 8000 maxblocks | 4791.5 | 5352.5 | 0.90 |
Pipe Throughput | 1568.3 | 3100.4 | 0.51 |
Pipe-based Context Switching | 948.2 | 1632.1 | 0.58 |
Process Creation | 1818.4 | 2091.3 | 0.87 |
Shell Scripts (1 concurrent) | 3452.5 | 3749.8 | 0.92 |
Shell Scripts (8 concurrent) | 3211.3 | 3468.8 | 0.93 |
System Call Overhead | 1018.8 | 3756 | 0.27 |
System Benchmarks Index Score | 2154.1 | 2831.9 | 0.76 |
しかしこれは。。。事前情報として知らされてはいましたが、やはり実際に目の当たりにするとショックです。というか、これを甘受しなきゃいけないわけですが、率直に言って、はいそうですか、とは受け入れられないレベルです。実際問題、システム周りがこれだけスループットが落ちるというのは、DBはじめ大量のファイル等データを処理するタスクではシステムの再設計が必要になるし、処理時間の増大に合わせて運用のスケジュールも変更を強いられる事になりますが、それは勿論必ずしも容易な事ではありません。何より莫大なコストがかかります。増強するにしても、機材費は無論、スペースとか電力とかそのための資金はどうすんのさって話で。少なくとも採算の悪化は避けられませんし、資金が不足したり、採算が合わなくなってビジネスが立ち行かなくなる事業者が出ても全く不思議ではありません。
正直、運用面の変更で回避する方法を模索するか、それが無理ならAMD等の比較的マシなプラットフォームへの切替えを検討せざるを得ません。でもそんな予算ないよ、と。参りました。マジで頭が痛いです。というか、これはもうIntelから賠償等がなされなければ収まらないのではないでしょうか。要求される側のIntelについては自業自得としか評価しようがないし、むしろ地獄に落ちろと思う位なのですが。あーもう。
ところで、数日前にASUS製マザーボードJ3455M-E(Apollo lake)の新BIOSがリリースされていました。ようやくIntel ME,TXEの脆弱性に対応したのか、と思って適用してみたのですが、TXEは修正されておらず、適用しても判定結果はvulnerableのまま。糠喜び&徒労でした。どうもそっちは放置で、本件対応を優先させたようです。ユーザにとってはどっちも同じ位深刻な筈なんですが。。。あっちもこっちも無責任なやつらばかりで、もううんざりです。
(追記)
Ubuntu16.04LTSの最初に公開された対策済カーネル(4.4.0-108)には、ブート出来なくなる不具合があったんだそうで。私が適用した時点では既に4.4.0-109に差し替えられた後でしたが、危うく被害を被るところでした。把握していたわけではありませんが、少し待ったのが功を奏したという形になります。しかし本当に信用なりませんねCanonical。
[関連記事 [PC] Meltdownに続き、Spectre脆弱性発覚でCPU全陣営が一斉崩壊の危機]
[関連記事 [PC] ここ十年のIntel製CPUほぼ全てにハード修正不能でソフト対処後数割性能低下の脆弱性発覚]
[関連記事 [PC note] 今更ながらのApollo lakeが意外といい感じ]
[関連記事 [PC] 現行Intel製チップのファームウェアの大半に脆弱性発覚]