AMD Zen2コアの脆弱性(CVE-2023-20593)

AMDのZen2コアの脆弱性が発表されました。
https://nvd.nist.gov/vuln/detail/CVE-2023-20593
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

例によってGoogleのセキュリティチームが発見したもので、開発者は思ってもいなかった脆弱性を掘り起こされて可哀そうだなと思っていたのですが、よく見るとこれは脆弱性以前に論理バグですね。

今までの殆どのCPU脆弱性は、論理的には正しい動作（ソフト可視のアーキテクチャステートは正しい）が、投機実行の残骸を非アーキテクチャステート(実行時間など)で読み取るというものでした。

しかし今回の問題は、アーキテクチャステートが誤った値になります。具体的にはvzeroupperという命令でYMMレジスタの上位を投機的にゼロクリアしたあと、分岐予測ミスが発生して該当命令をキャンセルした場合にYMMレジスタの上位がゼロクリア「前」の値に戻らない場合がある。

通常レジスタライトする命令はライトデータを保持するリネームレジスタを新しく命令デコード時に割り当てるのですが、vzeroupper命令ではリネームレジスタを新規に割り当てず代わりにゼロにしたよというフラグをたてて、ライトされる前のリネームレジスタを開放してしまう。

このリネームレジスタは解放されているので後続命令で使われて投機的に値を書き込まれる可能性がある。この後分岐ミスが発生するとゼロフラグをリセットしてリネームマップを元に戻すのですが、リネームレジスタの内容は書き換わっているので、該当レジスタの値（アーキテクチャステート）が元に戻らない。

脆弱性は書き換わったデータを読めてしまうからですが、そもそもアーキテクチャステートが戻らないのが問題です。

このバグは検証テストで見つけるのは結構大変ですが、でも(言うのは簡単ですが)出荷前に見つけておくべきバグと思います。

それにしてもなんでこんな制御にしたのでしょうか。YMMのリネームレジスタ数不足による性能低下を抑えたかったのですかね(私の勝手な推測です)。

詳細はGoogleチームのレポートが一番詳しいと思います。
https://lock.cmpxchg8b.com/zenbleed.html

(2023/8/4追記)
この問題はZen2固有でZen3には無いようです。理由がないとこういう制御は変更しないと思うのですが、脆弱性云々はともかく論理バグに気がついてzen3は設計途中で修正した、というのはあるかも知れませんね。