GoogleはSpectreとMeltdownの対策を昨年6月に開始し12月には完了していた。性能低下の報告はなし

2018年1月15日

インテルやAMD、ARMなど、現在使われているほぼすべてのCPUに影響する深刻な脆弱性「Spectre」と「Meltdown」が表面化した問題について、Googleはすでに半年以上前、2017年6月にこの脆弱性への対策を開始し、12月には完了していたことを明らかにしました。

現時点では多くの報道などにおいて、この脆弱性に対処するための修正を行うとCPUの性能低下を引き起こす可能性があることが指摘されています。またインテルは脆弱性対策のためのファームウェアを適用すると、デスクトップPC向けのベンチマークにおいて、6パーセントかそれ以下の性能低下の可能性があると発表しています（サーバ用途における性能低下の影響についてはまだインテルから発表されていません）。

ところがGoogleは、12月に完了した脆弱性対策のあともシステムの性能が低下したとの報告はなく、対策したことすらユーザーに全く気付かれなかったとしています。

2017年6月、Googleは脆弱性に気が付いた

1月3日、まだこのCPUの脆弱性に「Spectre」や「Meltdown」といった名前が付く前にGoogle Security Blogにポストされた記事「Today's CPU vulnerability: what you need to knowでは、このCPUの脆弱性をGoogleの「Project Zero」チームが昨年発見したことが紹介されています。

では、それは昨年のいつだったのか？

1月5日付のGoogleのオフィシャルブログであるThe Keywordにポストされた記事「Answering your questions about “Meltdown” and “Spectre”」では、同社が昨年2017年6月に、このCPU脆弱性への対策を開始したことが記されています。

Google’s engineering teams began working to protect our customers from these vulnerabilities upon our learning of them in June 2017. We applied solutions across the entire suite of Google products, and we collaborated with the industry at large to help protect users across the web.

2017年6月、Googleのエンジニアリングチームは脆弱性から顧客を守るために作業を開始しました。Googleの全製品に対して解決策を講じるとともに、Web全体の顧客保護を行うために業界での協力を行いました。

2017年9月、Variant1と3の対策を本番インフラにデプロイ

そして1月11日付で同じくThe Keywordにポストされた記事「 Protecting our Google Cloud customers from new vulnerabilities without impacting performance」では、2017年9月にはGoogleのインフラ全体、つまり検索エンジンであるGoogle SearchのインフラやGoogle Appsや、もちろんGoogle Cloudのインフラに対して脆弱性対策のためのソフトウェアをデプロイしていったと説明されています。

ただしこのときデプロイされたのはVariant 1、2、3と3種類ある脆弱性のうちの、1と3に対応するものでした。

In September, we began deploying solutions for both Variants 1 and 3 to the production infrastructure that underpins all Google products—from Cloud services to Gmail, Search and Drive—and more-refined solutions in October.

9月には、クラウドサービスからGmail、サーチ、Google Driveなどを含むすべてのGoogle製品を支えている本番用インフラに対して、Variant 1とVariant 3への対策をデプロイし始めた。そして、より洗練された対策が10月に行われた。

このVariant1と3への対応は顧客にまったく気づかれなかっただけでなく、社内チームからも何の性能低下の報告を受けなかったと。

Thanks to extensive performance tuning work, these protections caused no perceptible impact in our cloud and required no customer downtime in part due to Google Cloud Platform’s Live Migration technology. No GCP customer or internal team has reported any performance degradation.

幅広いパフォーマンスチューニング作業により、これらの対策によるクラウドへの目に見える影響はなにもなく、Google Cloud Platformのライブマイグレーション機能によって顧客側のダウンタイムも必要ありませんでした。Google Cloud Platformの顧客からも、社内チームからも、性能低下の報告は一切ありません。

Google Cloudでは、ライブマイグレーションによって顧客側には影響を与えずに対策が行われたであろうことは、Publickeyの1月4日付の記事でも予想していたことですので、ここは予想通りでした。

一方、Variant 1と3の対策をしたあとでも性能面で低下した報告はないというのは注目すべき内容です。

Variant 2の対策は性能低下を引き起こす心配があった

9月から10月にかけてGoogleが行った脆弱性対策はVariant 1と3に対するものでした。なぜVariant 2に対する対策が行われなかったかというと、その時点でVariant 2への対策は大きな性能低下を引き起こす心配があったからだとGoogleは説明しています。

同じく「 Protecting our Google Cloud customers from new vulnerabilities without impacting performance」から。

Variant 2 was going to be much harder to mitigate. For several months, it appeared that disabling the vulnerable CPU features would be the only option for protecting all our workloads against Variant 2. While that was certain to work, it would also disable key performance-boosting CPU features, thus slowing down applications considerably.

Variant 2はより対策が困難でした。数か月の間、すべてのワークロードをVariant 2の脆弱性から守るためには、この脆弱性を抱えたCPUの機能を無効にすることが唯一の手段ではないかとみられていました。しかしそうすると、CPUの性能向上を支える重要な機能を無効にすることになるため、懸念されるほどアプリケーションの性能低下を引き起こすことになるでしょう。

対策ソフトRetpolineをついに開発

しかしついに、GoogleのエンジニアであるPaul turner氏が性能低下を引き起こすことなくVariant 3の対策を行う方法を発見します。それは「Retpoline」と名付けられました。Retpolineはリターン（return）とトランポリン（trampoline）を組み合わせて作られた造語です（ということは発音は「リタポリン」ですかね）。

With Retpoline, we could protect our infrastructure at compile-time, with no source-code modifications. Furthermore, testing this feature, particularly when combined with optimizations such as software branch prediction hints, demonstrated that this protection came with almost no performance loss.

Retpolineによって、コンパイル時にソースコードを変更することなくインフラを保護することができました。それだけでなく、この対策機能をテストしたところ、特にソフトウェアブランチ予測のヒントなどの最適化と組み合わせることで性能低下がほとんどなくなったのです。

Retpolineはオープンソースとして公開されており、GCC用の実装とLLVM用の実装が用意されています。

12月までに対策完了、誰にも何の変化も指摘されていない

GoogleはRetpolineによるVariant 2の対策も12月までに完了。そしてこのアップデート作業において、顧客からは何の指摘もなかったと。

During the entire update process,nobody noticed: we received no customer support tickets related to the updates. This confirmed our internal assessment that in real-world use, the performance-optimized updates Google deployed do not have a material effect on workloads.

アップデートのプロセス全体にわたり、誰もそれに気づきませんでした。顧客からこのアップデートに関連したサポート依頼はなかったのです。これにより、実稼働環境での利用においてGoogleがデプロイしたパフォーマンスオプティマイズ済みのアップデートは、ワークロードに重大な影響を及ぼさないという内部評価が確認されました。、

本当に性能低下はないのか？

Googleはくりかえし、クラウドの顧客から性能が低下したという指摘はない、と報告しています。これは、あらかじめ脆弱性対策の性能への影響がないことを断定することは困難であるため、実際のワークロードをじっくり観察する以外に影響を知る方法がないからであって、仕方のない表現です。

とはいえ、脆弱性対策が行われたことについて知らされていない顧客は、多少の性能低下があっても一時的なものか深刻なものではないと考え、気にしていない可能性もあります。

性能低下の可能性がある脆弱性対策が行われたことを知った顧客は、これから過去のログを引っ張り出して性能を慎重に比べるようになるはずです。

本当のところ現実にどれくらいの性能低下になったのか、あるいは本当に気付かないほど性能への影響はわずかだったのかは、これからさまざまな報告の積み重ねが行われたあとで分かることなのではないでしょうか。

と書いたものの、実はAWSもSpectreとMeltdownの対策報告として、Amazon EC2での性能低下は見られないと書いています。膨大な顧客だけでなく自社システムもクラウド上に抱えるGoogleとAWSであれば、短期間であっても非常に多くの実システムの稼働状況を把握できるはずで、その結果として性能低下が見られなかったのであれば、これを否定するのは難しそうです。

少し長くなったので、AWSによる報告については次の記事「AWSもSpectreとMeltdownの対策完了を報告。対策後、Amazon EC2で性能の低下は見られないと」で紹介します。