AMDのZen 1「ゼロ除算」バグに対するパッチは、同社が期待していた通りの完璧な解決策ではありませんでした。パッチのリリースは迅速でしたが、少し早すぎたかもしれません。PhoronixのMichael Larabel氏によると、AMDのLinuxエンジニアであるBorislav Petkov氏が、元の解決策（これも彼自身が公開したもの）の問題を修正した新しいパッチを公開しました。これは、起こり得る攻撃ベクトルに対するセキュリティ強化の難しさを示す、新たなデータポイントです。
元々のバグは、Zen 1が特定の状況下で整数を0で割る計算を処理する方法に関係していました。調査結果によると、AMDのCPUは演算が完全に完了した後もレジスタ内に「古い商データ」を保持する可能性があり、攻撃者に機密情報を取得する機会を与えてしまう可能性がありました。当初の回避策は、#DE例外ハンドラから戻る前に最後に「ダミーの0/1除算」を実行することでした。考え方は単純で、0/1除算（結果は常にゼロ）の完了時に、まだ保存されている古いデータが消去されるというものです。
したがって、ユーザー空間へのすべての出口で無害な除算を実行し、ユーザー空間がカーネル空間での整数除算からの潜在的に古いデータを参照しないようにします。
ホストデータがゲストに漏洩するのを防ぐために、VMRUN の前にも同じことを行います。
CPU分野の脆弱性に関しては、AMDとIntel両社が相次いで公開され、既に慌ただしい月となっています。Intelのより深刻なDownfall脆弱性（SkylakeからTiger Lake/Rocket Lakeまで影響）から、AMDのSQUIPおよびInception脆弱性（そして現在修正済みの「ゼロ除算」脆弱性）まで、研究者たちは懸命に取り組んできました。MeltdownやSpectre時代の名高い歴史には到底及びませんが（ただし、これらの新しいバグは投機的実行の脆弱性にも関連しています）。投機的実行とは、現代のCPUが計算ステップが必要になる前に先回りして実行しようとする手法を指します。これにより、実行時に必要なデータが既に利用可能になります。これらの脆弱性の一部に対する修正は（時には深刻な）パフォーマンスの低下を招きましたが、AMDの0/1ダミー除算には追加のオーバーヘッドが伴わないことは、少なくとも良い兆候と言えるでしょう。
同時に、少なくともこのケースでは、セキュリティ パッチが「設定して忘れる」ようなやり方でリリースされなかったことは心強いことです。ブルー チームの専門家がこなさなければならないメリーゴーランドのような作業では、他の方法で解決できた可能性もあります (欠陥のあるパッチが完全に機能すると信じられ、将来的にさらなるハッキング調査が行われる可能性もありました (それがどのような影響を与えるかはわかりませんが))。
Tom's Hardware の最高のニュースと詳細なレビューをあなたの受信箱に直接お届けします。
Francisco Pires 氏は、Tom's Hardware のフリーランス ニュース ライターであり、量子コンピューティングに関心を持っています。
