そう、Linuxカーネルのセキュリティの神話は、ただの神話だよ。

これはローカル特権昇格のエクスプロイト（通常ユーザーからrootになること）で、リモートコード実行ではないよ。特権昇格のバグは山ほどあるからね。

サーバーは2週間ごとにオープンしてたよ。作業証明は接続を少し遅くして、できるだけ多くの接続リクエストをスパムするインセンティブを減らすためのものだった。パブリックCTFは難しいんだよね、どうしてもどのチームかがゴールに向かってDDoSに似たことを試みるから。これがあった後、Googleは作業証明のステップを取り除いたんだ。

修正したよ :) ありがとう！

12世代（そのパフォーマンスコアと効率コアの概念）では、数ヶ月後にそれを無効にしちゃって、それ以降は見かけなくなったんだ。パフォーマンスコアを持つ12世代のCPUは、AVX512のサポートを宣伝すらしてなかったし、初めから有効にもなってなかった。効率コアにはスペースの関係でAVX512が含まれてなかったから、全体のCPUがAVX512を持ってないと見なされてたんだ。効率コアを無効にして残りのCPUでAVX512を有効にするには、BIOSのオプションのちょっとしたトリックを使う必要があった。Eコアを諦める必要があったんだよね。

それは納得できるね。数ヶ月前のIntelの更新されたAVX10ホワイトペーパーがこれを確認しているみたい。512ビットのAVXがPコアとEコアの両方で標準になるって明言してるし、256ビットだけの構成から移行するってさ。これはAVX-512が本格的に復活することを強く示唆してるね、サーバーだけじゃなくて、将来の消費者向けCPUでもEコアと一緒にね。AMDのAVX-512の普及に追いつこうとしてるんだろうね。

おお、面白いね。開発中にこれを見ておくべきだったな…。そのコードは、例えばZen 5用にもう一つのバージョンが必要そうだね。zmmレジスタを使うことで、2倍の乗算スループットが得られるはず。あと、マスクレジスタが算術用にGPRにバウンスされるけど、Zen 4/5では最適じゃないんだよね。別に、キャリーを一度に伝播させる必要があるのか気になってる。 （少なくとも、そうなってると思うけど？）キャリーインが高位12ビットにあるものを超えて追加のキャリーアウトを引き起こす可能性は非常に小さいから、私のコードではキャリーは一度だけ発生して、必要ならループバックする前提にしてる。それで、一般的なケースでのレイテンシが減るんだ。ただ、分岐があるとタイミング攻撃の問題が出るかもしれないね。

Googleのコードの「exponent = (p + 1) // 4」は2^1277だよ。そんな巨大な数を累乗するには、1277回平方するんだ（それがPythonの関数がやってること）。最初の値が「x」なら、平方するたびに「x」の数が倍になるから、最後には2^1277になるんだ。

それは別のメタゲームになるね。深く考えたわけじゃないけど、結果的には人々がやる気を失って、kernelCTFに提出することを考えなくなるんじゃないかな。

それに加えて、これって人々が脆弱性をすぐに報告するんじゃなくて、次回のために温存しちゃうことを助長してる気がする。報告タイミングのトリックがなくても、次回提出できるようにってね。だから、実際に「間違った」ことを促してる可能性もあるよね。

ボスがそのクールなプログラムを運営するために厳密な予算を求めてるんだ。これらのプログラムの理由（少なくとも部分的には）は、エクスプロイトや緩和策のダイナミクスを測ることであって、バグを買うことじゃないんだよね。Linuxはバグが多すぎて、0-dayごとにお金を払うと制御が効かなくなる。Googleも一度そうしようとしたけど（人々が蓄えていたバグを引き出すために）、期間限定のプロモーションをやったら、すごい量の応募が来ちゃった。同時にコミュニティを怒らせたくないから、こうなってるんだ。