不安定問題に脆弱性問題……CPUのメンテナンスは大変

　今月はCPUに纏わる話を3つほど。

IntelのRaptor Lakeのマイクロコード改修

　5月の記事でもちょっと触れたが、Raptor LakeのK/KSモデルの劣化問題。5月の時点ではまだその根本原因は不明のままであり、ただし現象的にはOCのやり過ぎで内部回路が損傷したのと同じような状況が確認できたためであろう。5月の時点ではそうしたOC動作を抑制するために、Intel Baseline Profileという、コンサバティブな動作をするBIOSがマザーボードメーカー経由で配布されることになった。

　ただこの劣化問題はOC動作をしていないCPUでも発生する、ということでこれは根本原因ではなかった。6月18日、Intelは「依然として根本的な原因は判明していないが、この調査の途中でeTVB(Enhanced Turbo Velocity Boost)のアルゴリズムにバグがあることを発見した」とし、7月にこのeTVBのバグを修正したマイクロコード0x125の配布を(やはりマザーボードベンダーなどを経由して)開始している。

　ただこれも根本的な原因ではない。そこで8月9日、新しいマイクロコード0x129の配布を開始した。こちらでも報じている話だが、CPU内部で電圧制御を行なう際、1.55Vを超える電圧を印加しようとした場合には、それを1.55Vまでに抑えるという仕組みである。

　説明によれば、問題の現象が起きているプロセッサでは、複数のコアにおいてVmin(最低動作電圧)が大幅に上昇していることが判明しているそうだ。このVminの上昇は、(原因不明の要因による)電圧上昇の時間蓄積によってもたらされる可能性がある、としている。

　そこで、とりあえず1.55Vを超えるような電圧の印加を抑制することで、回路の損傷を防ごうというわけだ。そもそも1.55Vを超えるような電圧の印加が通常(=ユーザーが明示的にOC動作を行なっていない)の状態で行なわれるのがおかしいのではあるが、その要因を掴み切れていないために「1.55Vを超える電圧の印加を行わないようにする」という対策は取れない。なので、「仮に1.55Vを超える電圧の印加の指示が(CPUのどこからか)発生しても、1.55Vで止める」というのが今回のマイクロコード更新の概要である。

　このマイクロコード0x129に関してのIntelの社内評価の結果は、たとえば3DMark TimespyやWebXPRT 4、CinBbench R24、Blender 4.2.0などでは明示的な差はみられない(測定誤差の範囲)が、WebXPRT Online HomeworkとかPugetBench GPU Effects Scoreなどでは中程度の影響があったのだそうで、これは要するにちゃんと更新されたマイクロコードが仕事をしている証拠でもある。

　ただ厄介なのは、そもそも1.55Vを超える電圧の印加が直接的な原因かどうかもまだ不明なことだ。

　たとえばであるが、障害の原因が電圧の絶対値ではなく電圧の上昇速度だったとしたら、このパッチでは解決できない。

　SpeedStep以来、長い歴史を持つDVFS(Dynamic Voltage and Frequency Scaling)は、動作周波数に合わせて印加する電圧も変化させる仕組みだが、仮に600MHz@0.65Vから3GHz@1.20Vに動作周波数を上げたいと思った時、いきなり0.65Vから1.2Vまで電圧を上げても周波数は追い付かない。なので0.65V→0.70V→0.75V→……と少しずつ刻んで電圧を上げながら、同時に動作周波数を少しずつ引き上げてゆくことになる。

Pentium 4 660における動作周波数向上の過程(2005年撮影)

　この際にどのぐらいの時間間隔で、どの程度の刻み幅で電圧を引き上げるのか？というのはプロセスによって変わってくるので、一概には言えないのだが、これを無視していきなり0.65Vから1.2Vに電圧を上げたりすると、損傷の要因になる可能性はある。そうした現象が起きていたとすると、今回のマイクロコードでは根本的な修正にはならないことになる。

　これはあくまで一例であって、実際にそうした現象が起きているかは不明だし、もっとほかの要因かもしれない。要するに根本的な要因が未だに掴めていないという状態では、今回のマイクロコード0x129は気休めにしかならない。

　このあたりのことはIntelも重々承知しており、なので説明でも「マイクロコード0x129は不安定症状が発生していないプロセッサに対する予防的緩和策」(The latest microcode update (0x129) will limit voltage requests above 1.55V as a preventative mitigation for processors not experiencing instability symptoms.)としている。

　先の記事では「不安定動作を解決するパッチ」としていたが、実際には「まだ不安定動作に陥っていないプロセッサに対する予防的パッチ」という方が実情に近い。

　問題そのものは昨年(2023年)末位から報告が出始めており、遅くとも今年(2024年)2月には調査が始まっていたことを考えると、既に半年余りを経過しても未だに問題の根源が掴めていないことになる。

　既に問題は、Raptor Lake自身の問題だけでなく、Intelの検証(Validation)プロセスそのものの信頼性が問われる事態になっているのは間違いない。今回の問題はRaptor Lakeだけで済まず、今後登場する製品に対しても検証の見直しが求められる(単に社内だけでなく、OEM/ODMもそれを望むだろう)ことになる。

　運が悪いというかなんというか、今は間もなくLunar LakeベースのCore Ultraに加えてXeon 6の出荷が始まり、さらにその後にはArrow Lakeが控えているというタイミングである。このタイミングで、そうした製品の検証の見直しは、Intelの検証チームに死人が出かねない負荷増になるだろう。

　さらに追い打ちを掛けているのが、8月2日に行なわれた第2四半期の決算発表である。GAAPベースで粗利35.4%、営業損失20億ドルと第1四半期を上回る損失が出ており、これを受けて100億ドル規模のコスト削減プランを打ち出しているが、当然この中には人員削減も含まれている。仕事が増えて人が減った状態で本当に真っ当に検証を行なえるのか？というのは筆者ならずとも考えてしまうところだろう。

2024年6月末締めの第2四半期決算

　こうしてみると、4月の記事に書いた「要するに『やり過ぎた』のだ。」は、一周回って正しかったと思わざるを得ない。4月の時には単純に「性能を上げるために消費電力突っ込み過ぎである」程度の意味合いだったのだが、今では「性能を上げるために消費電力を無理やりにでも上げるために複雑な仕組みを突っ込み過ぎて、問題の解析すらできなくなっている」ことが見えてきたことになる。これ、そこまで性能を追求しなければ、ここまで複雑な仕組みは必要なかったことになる。

　半導体の世界では良くPPA(Power, Performance and Area) Optimizationという言葉が出てくる。性能と消費電力、コスト(Area=ダイのエリアサイズで、要するにそのままコストに直結する)は相反する要求であり、各々の要求をどう満足させるかはバーターである。そしてIntelはこれを思いっきりPerformance(性能)に振り過ぎてしまった結果が現在の状況を招いていると考えざるを得ない。Arrow Lake以降の製品ロードマップに、今回の教訓が生かされると良いのだが。

AMDの脆弱性(CVE-2023-31315)対応のマイクロコード改修

　Intelに負けじと(？)AMDも8月9日にマイクロコードのアップデートをアナウンスした。この件も既に記事になっているが、要するにSMM(System Management Mode)に簡単にアクセスできてしまうため、これを利用してシステムに侵入されてしまうというものだ。

　EPYCやEPYC Embedded、Ryzen Embeddedに関しては、まだ運用されているシステムがあることを考慮してか第1世代から対応マイクロコードの提供があるが、モバイル/デスクトップ向けはRyzen 3000シリーズ以降での対応になる(先の記事では、デスクトップ向けのRyzen 3000シリーズは未対応と報じられていたが、AMDの対応ページにいればRyzen 3000シリーズのデスクトップ(Matisse)は2024年8月20日を目標に更新の提供予定となっている)。

　もちろんAMDとしても全製品に対応するのは時間が掛かるので、たとえば現状でもEPYC Embedded 3000/7002/7003とかRyzen Embedded V1000/R1000/R2000/5000/7000などは2024年10月提供予定とされるなど、さすがに全製品に対して同一タイミングでのマイクロコード更新は無理だったようだ。急げば何とかできるかもしれないが、当然検証が不十分になる。「更新したら動作がおかしくなった」とかいう事態を防ぐためにも検証の時間を確実に確保するのは重要だし、その結果として多少提供時期が遅れるのは致し方ないだろう。

　マイクロコードの更新はBIOSアップデートを利用する格好になっているのはIntelと同じである。さすがにOSレベルでのマイクロコード更新は無理ということだ。そろそろRyzen 1000/2000を使っているユーザーも少ない(*1)ということを考えると、まぁ妥当と言えば妥当な策だとは思うが、現象的にはなかなか致命的な問題である。

　CVSSのベーススコアは7.5とされている。最高のスコアは10.0で、9.0～10.0が緊急、7.0～8.9が重要扱いされており、そこから言えば「今すぐに更新するほどの緊急性はないものの、放置しておくのはヤバいので早急に対応を」というあたりだろうか。なのでWindows Updateなどシステム更新の際には、マザーボードベンダーから最新BIOSを入手してアップデートを行なっておくことを強く推奨したいところであるが、問題はこうした古い製品だとマザーボードのBIOSアップデートが遅れ気味なことだろう(マザーボードベンダーも暇ではないからだ)。

　筆者の場合で言えば、ASUSの「TUF GAMING X570-PLUS」については、現時点で公開されているのが今年4月4日付のComboV2PI 1.2.0.Ca対応であり、今回Ryzen 4000シリーズやRyzen 5000シリーズに必要とされるComboAM4v2PI 1.2.0.cbではない。これが対応されるのをとりあえず待つしかなさそうだ。

RISC-Vにも脆弱性

　8月7日、ドイツの CISPA Helmholtz Center for Information Securityは、RISC-Vプロセッサの脆弱性を検知するためのフレームワークであるRISCVuzzと、このRISCVuzzを利用することで発見されたGhostWriteと名付けられた脆弱性に関する論文を発表した。

　チームは2社5種類の商用64bit RISC-VプロセッサにRISCVuzzを掛けて試験を行ない、この結果3種類の脆弱性を発見したことが報じられている。比較対象は

で、このうちT-HeadのC906/C908/C910では仮想メモリではなく直接物理メモリにアクセスして、内容を読み取ったり変更したりすることが可能であることが発見された(ここにPoCコードの実行の様子が動画で紹介されている)。

T-Head C910搭載のMilk-V Meles

　さらに“Halt-and-Catch-Fire”と呼ばれる、非特権にもかかわらずCPUを停止させられる脆弱性も発見された。加えて、T-Head C910に関しては、ほかのCPUならセグメンテーション違反が発生する命令が正常に実行できてしまうことも発見されている。

　原因はT-Headのプロセッサのインプリメントの問題で、ベクタ拡張命令の実装にあたって未定義命令(vse128.v～vse1024.v)が来た時に、本来ならセグメンテーション違反で落とすべきなのに落としていないとか、T-Headの追加した拡張命令にバグがあって特定のシーケンスおよび条件でCPUが停止するといったものが直接的な脆弱性の要因である。

　ちなみにU54やU74ではこうした問題は発生しておらず、なので「RISC-Vにも脆弱性」というよりは「T-HeadのRISC-V CPUに脆弱性」というのが正しい見出しなのだろうが。

　論文の後半の議論の節で「もしRISC-Vプロセッサにx86と同じようなマイクロコードのレイヤーがあれば、ここで命令をフックしてパッチを当てることが可能であり、これでベクタ命令の問題を回避して単にセグメンテーション違反を発生させることができただろう。ますます複雑になるRISC-Vプロセッサにも、将来発見される脆弱性への対応を可能にするために、マイクロコードレイヤーを設けるべきであると提唱する」(We assume that with a microcode layer, as on x86, GhostWrite could be mitigated. An x86 microcode update can hook and patch instructions [5], which could have been used to hook the broken vector instruction and simply raise an illegalinstruction exception. Given the increasing complexity of RISC-V CPUs, we advocate such a microcode layer on RISCV to have the possibility of mitigating CPU vulnerabilities.)なんて書かれていたりする。

　要するに、後から動作を修正できるような仕組みが現在のCPUには欠かせないという話であり、実際にIntelやAMDがこれを活用して今回の問題に対処していることを考えると、RISC-Vにもマイクロコードレイヤーの搭載は必須になっていくだろう。CPUのメンテナンスも大変な時代になった、としみじみ感じる。