セキュキャン2025 SGXゼミ 課題晒し

2025/08/07

IPAのセキュリティキャンプ 2025に応募し無事に合格しました。

応募したゼミは「TEEビルド & スクラップゼミ」です。当初は合格するとは考えておらず、課題晒しも行うつもりはありませんでした。

しかし、SGXゼミの課題晒しが非常に少ないということを踏まえ、せっかく合格したので公開しようと思います。

感想

SGXとはなにかについてほんのり調べ始めたばかりだったので色々と間違っていることや理解できていないことが書いてあったりします。

LLMをフル活用して書いているので正直恥ずかしいという気持ちも大きいです。強くなれるように頑張ります。

NoteBookLM

https://notebooklm.google.com/notebook/5cf65388-2ff4-4fd5-9311-44f5224a5157

今回の課題作成にあたって上記のNoteBookLMを作成して用いた。

課題

以下は課題の転載です。

# TEEビルド&スクラップゼミ応募課題
 
* 本応募課題では、各問難易度を高めに設定しており、(コード実装含め)完答を前提としてはおりません。  
  同時に、ゼミの主題であるTEEへの(スタンス的な)適性や、解答までのプロセス、熱意を測る意味合いを多分に含めています。  
  完答が難しい場合、途中までの調査結果や思考内容、自らの意見等を記述していただければ、そちらも大きく加点対象といたします。  
 
* 文字数が多い事により採点に有利になることはありません。  
 
* フォームの文字数制限を超過する場合は、外部サービスを利用し限定共有の形で共有いただいて構いません。  
 
* この応募課題のテキストは、Markdown形式で記述しているため、Markdownとして表示する事ができます。  
 
* 解答を作成する上で、各種参考文献やサービス(LLM等)を参照するのは全く減点要素にはならず、寧ろ大歓迎です。  
  ただし、文献やサービスを参照した際には必ず参考文献を記載してください。  
  LLMで解答を導出し、論拠となるサイトや文献の特定に失敗した場合、使用したLLM名(サービス、モデル)も必ず明記してください。  
  (DeepResearch等による助力含め、LLMの回答の論拠を特定できた場合は不要です)  
 
TEEやその実装例の1つであるSGXについての基本的な前提知識については、例として以下の文献を参考にしてください(勿論以下の文献に限りません)。
 
* https://www.ieice.org/~dpf/wp-content/uploads/2021/08/DFS研究会産総研須崎.pdf
* http://www.ipsj.or.jp/sig/os/index.php?plugin=attach&refer=ComSys2020&openfile=ComSys2020-Suzaki.pdf
* https://acompany.tech/privacytechlab/author/ao-sakurai
* https://qiita.com/Cliffford/items/2f155f40a1c3eec288cf
* https://qliphoth.io/seccamp/
 
# 簡易的な前提知識
 
TEEとは、ハードウェア(主にCPU)により厳重に隔離された領域にデータを保持し、その状態で隔離保護領域用に定義された  
コードを実行する事で、終始データを保護しながらそのデータを利用した処理を可能とする技術です。  
特に、Intel SGXにおいてはこの隔離保護領域を「Enclave」と呼びます。SGXのEnclaveは、CPUの極めて特権的な制御により  
隔離されている上、その全域がAESベースで暗号学的に保護(暗号化)されているという特長を有しています。
 
# 問題
 
## Q1
 
あなたがTEEを使用して実現してみたいプロダクト(アプリケーションやシステムなど)を、理由と共に紹介してください。  
セキュリティに対する興味を交えて紹介いただけるとベターです。  
その上で、本ゼミでメインとして取り上げるIntel SGXは、その利用・開発の際にC/C++に強く依存するため、最低限のC/C++のスキルがないと  
一切の開発を行う事ができません。  
そこで、C/C++(特にC++)を使用して行ったものや開発したものがあればそれについても説明してください。  
GitHub等に自作のコードがあれば、そのリンクも共有してください。  
もし経験がない場合は、ゼミ本番までのC++の習得に関する計画を述べてください。経験の有無自体が採点に影響する事はありません。  
 
## Q2
 
Intel SGXにおいては、それがいかに重要な機能であっても、比較的唐突かつ十分な猶予無しに廃止を宣告される事があります。  
例えば、種々の信頼可能な機能を提供していた、Intel製の特別なEnclaveであるPSE(Platform Service Enclave)がこれに該当します。  
また、リモートに存在するEnclaveやそのSGXマシンの正当性(信頼可能か)と完全性(コードが改竄されていないか)を検証するために、  
Remote Attestation(RA)という手続きが必要ですが、今まで主流であったEPID-RAという方式のRAが、突如サービス終了を宣告され、  
2025年4月にはもう完全に使えない代物となってしまいます。  
さらに言えば、クライアント向けCPUであるCoreシリーズでも第6~10世代でSGXに対応していましたが、第11世代以降突如SGXが削除され、  
現行のCPUとしてはXeonプロセッサでのみSGXを使用可能です。  
 
あなたは、これらの機能やSGX自体をヘビーに使用している状態で、もしこのような唐突な廃止を宣告された場合どのように思いますか。  
また、上記のIntelによる運用は褒められたものでは無いと考えられますが、それでもIntelがそうせざるを得なかった理由と、  
本来取るべきであった理想的な運用についても考察(あるいは調査)して回答してください。  
 
## Q3
 
TEEには、通常のOSすら信頼不可能と見なして特定のコードのみを信頼可能とする「部分隔離型」と、  
VMを丸ごと隔離保護する(つまりはOSも丸ごと内包し信頼する)「VM型」の2種類が存在します。  
部分隔離型には、本ゼミでメインとして扱うIntel SGXに加え、ARM TrustZoneやRISC-V Keystoneが存在します。  
一方、VM型としては、Intel TDX、AMD SEV、ARM CCAが主なものとして存在します。  
 
ここで、SGXのような部分隔離型では対処できるものの、TDXのようなVM型では対策できない攻撃シナリオを考察し説明してください。  
攻撃シナリオについての説明は、具体的なあるサービスにTEEを使用する想定での説明でも、より一般化した議論としての説明でも  
どちらでも構いません。
 
## Q4
 
この大問Q4は、属する小問Q4-1~Q4-2から自由に選択し解答する選択問題の形を取っています。各大問での指示に従い、  
問題を選択して解答してください。  
余力があれば指定された選択数よりも多くの問題に解答しても構いません。  
 
### Q4-1
 
C++において、文字列"Hello, TEE."(または、お好みの文字列やバイト列があればそちらでも可)に対する、  
単一の128bit AES-CMAC値を算出するプログラムのソースコードを書いてください。  
結果のMAC値を16進数表現で出力するようにし、実行結果の
鍵は、128bitの鍵を毎回乱数的に動的生成して使用してください。  
OpenSSLで実装するのが比較的楽であると思いますが、その場合はOpenSSL公式GitHubリポジトリのサンプルコードも参考になります。  
https://github.com/openssl/openssl/tree/openssl-3.4.1/demos/mac  
ただし、システムコール(例:system, fork+exec)によりopensslコマンド等を呼び出すような実装は不可とし、  
C/C++コードから直接OpenSSL等の暗号ライブラリを用いて実装するものとします。  
 
実装の上で必要な前提知識については、例えば以下の文献を参考にしてください。  
 
* https://edn.itmedia.co.jp/edn/articles/1810/10/news012_3.html
* https://tex2e.github.io/rfc-translater/html/rfc4493.html
* https://ja.wikipedia.org/wiki/CMAC
 
### Q4-2
 
お好きなコンピュータにおいて、以下に示す特定のモデル固有レジスタ(MSR)を読み取り、得られたビット列が意味する内容を解説してください。  
ただし、MacではこのようなMSRの読み書きが難しいため、Mac以外のマシンで実行するものとします。  
ビット列が意味する内容を解説する際に出てくる専門用語(例:IBRS、MDS)についても、可能な範囲で調査し軽く解説してみてください(必須ではありません)。  
 
MSR自体の基礎知識については、例えば以下のサイトを参照してください。  
https://mcn.oops.jp/wiki/index.php?CPU%2FMSR  
 
#### Intel CPUのマシンである場合
 
IA32_ARCH_CAPABILITIES(MSRアドレス:0x10A)を読み取り、返ってきた値をビット表現し、各bitが何を意味しているかを解説してください。  
つまり、各bitが何を示すビットフィールドであり、あなたのマシンで出力されたそのbitがどのような状態を示しているかを説明してください。  
例えば0x02Fと返ってきた場合、0b000000101111のようにビット表現し、各bitが何を意味しているかの説明をする形となります。  
 
#### AMD CPUマシンである場合
 
SPEC_CTRL(MSRアドレス:048h)を読み取り、返ってきた値をビット表現し、各bitが何を意味しているかを解説してください。  
解答方法に関しては上記のIntel CPUマシンの場合と同様とします。  
情報源については、AMD64 Architecture Programmer’s Manualを見ると正確です。
 
#### 上記MSRを読み取れない環境の場合
 
手元にMacしか無い、あまりにも古いマシンしか無い等の理由により、上記MSRを読み取れない場合、任意の他のMSRを選んで読み取り、  
その内容について説明してください。  
Macであれば、カーネル拡張(kext)を用いると間接的にMSRを読み取れる場合があります。  
https://larry1301.wordpress.com/2015/12/14/macbook-cpu-throttling-motherboard-thermal-sensor-and-bd-prochot-msr/  
 
それでも読み取りが難しい場合は、そのマシンにおいてMSRを読み取れない理由について考察してください。  
さらに、Intel CPUマシンの場合の部分で取り上げているIA32_ARCH_CAPABILITIESについて、各bitフィールドが何を表すためのものなのかを  
それぞれ説明してください(実際のbit値を出す必要はありません)。
 
#### MSRの読み取り方法
 
原則として、ホストOSでしか読み取れない(VMからの読み取りは難しい)点に注意してください。
 
##### Linuxの場合
 
msr-toolsをapt等でインストールすると使用できるようになる、rdmsrコマンドにより簡単に読み取れます。
 
##### Windowsの場合
 
[RWEveryThing](https://rweverything.com/)というツールを用いると、GUIベースで目当てのMSRを読み取れます(閲覧できます)。  
以下リンク先の「Example #3: MSRs」で説明されている手順に従い、当該MSRの値を取得してください。  
https://www.basicinputoutput.com/2017/08/rweverything-yes-everything.html

Q1

TEEを用いて実現してみたいサービス

TEEはPETsの一種であり、準同型暗号と比較してオーバーヘッドの少ない秘密計算が可能である点が特徴である。

この特性を用いて開発したいプロダクトは、構成証明可能な差分プライバシー適用サービスである。これは、データ利用者からの要求に応じてデータ提供者の生データをDPに基づいて匿名化するクラウドサービスであり、その最大の特徴はTEEの構成証明機能を用いる点にある。

データ提供者は、宣言された通りのプライバシー保護処理が改ざん不可能な環境で確実に実行されたことを暗号学的に検証可能となる。このサービスが必要とされる背景には、従来のプライバシー保護サービスがサービス提供者への信頼に依存していたという課題が存在する。従来、提供者が特定のプライバシーパラメータを適用すると公言してもユーザーはそれを信じるほかなかったが、TEEの構成証明機能を用いることで、ユーザーはデータを送信する前に、サーバー上でデータを処理するプログラムが正しく、改ざんされておらず、正規のTEEハードウェア上で動作していることをリモートで検証できる。

この「信頼」から「検証」への転換こそ、TEEをプライバシー保護に用いる最大の価値である。本サービスの具体的な処理フローは次の通りである。まず、サービス提供者はDP処理を行うEnclaveコードとそのハッシュ値を公開する。データ利用者が分析をリクエストすると、データ提供者はデータを渡す前に構成証明を要求し、Enclaveの正当性を検証する。検証が成功した場合にのみ、データ提供者は生データをTEEとの暗号化通信路を通じて送信する。TEE内では、受け取った生データに対してリクエストされたパラメータに基づきDP処理が施され、統計的に安全になったデータが生成されてデータ利用者に返却される。

この一連のプロセスにおいて、データ提供者、データ利用者、そしてサービス提供者がそれぞれの役割を担うことになる提案は、TEEの高性能さという利点を活かしつつ、構成証明という核心となる機能を組み合わせることで、技術的に検証可能なプライバシー保護という絶対的な安全性を提供できる。

C/C++を用いた実装の例

私は群馬大学の情報メカトロニクス研究部に所属しており、C++とPlatformIOを用いて幾つかの制御のためのプログラムを作成していました。 また、大学の授業においてC言語で基本的な正規表現に対応したgrepもどきを作成し、その経験を活かしてJSONのパーサーの作成もしました。 低レイヤにおいては、Linuxカーネルを特定のデバイスに移植するためにドライバの一部の修正を行ったことがあります。

基本的な実装は行える一方で、C++固有のオーバーロードやスマートポインタといったモダンな機能についての理解は乏しいのが現状です。 ゼミ本番までに、理解の乏しい機能やムーブセマンティックといった概念の理解に努めようと思います。

また、Intel SGXのEnclave記述言語についての理解も同様に乏しい状況であり過去のセキュリティキャンプの講義資料やIntelのドキュメントを参考に学習する予定です。

Q2

SGXの機能廃止や仕様変更について

多くの開発者や研究者に指摘されている通りIntel SGX及びSGXSDKは非常に複雑であり、通常のアプリケーション開発の何杯もの労力と専門知識を要することで知られている。 そして実際にコミュニティはその労力をセキュリティに投じてきたが、Intel側はそれに対して"11世代以降のCPUにおけるSGXの非推奨"という回答を出した。 私はこれに対してコミュニティに対する裏切りと信用の失墜を招いた行為であり、行動に対して疑念を持たざるを得ないと感じている。

特に、Intel SGXのローカル側でEnclaveを作成するRAを実装した例としてPowerDVDのUHD-BDのAACS2の復号が挙げられる。 これはAACS2の鍵を保有しているサーバーから、PowerDVDを実行しているコンシューマーのPCに対してRAを行い、Enclave内でAACS2の復号を行うものである。 Intelの11世代以降のIntel SGXの非推奨化(Deprecated)により最新のPCではRAに失敗するためUHD-BDを再生できなくなった。 セキュリティと利便性はトレードオフであるとはよく言われる話ではあるが、ベンダー側の一方的な都合によりエンドユーザーに対して不利益が生じるのはいただけないと考える。 こういった変更の繰り返しは企業やTEE技術全体に対しての社会の信用を失い、DRM等への法令遵守の意識やセキュリティに対する意識の低下を招くのではないかと危惧している。

Intelの急な仕様変更を行った理由の考察

Intel SGXは発表当初は先進的なTEE実装であったものの、現在となっては多くの脆弱性や欠点が見つかっている。 特にForeshadow(L1TF)、Plundervolt、LVI (Load Value Injection)、SGAxe、Crosstalkといった数々のサイドチャネル攻撃が挙げられる。 これらはEnclave開発者側ではなくCPUベンダー(Intel)側の責任の領域の問題であることが多い。 こういった問題の修正はCPUのマイクロコードのアップデートを経由して行われているが、これはUEFIファームウェアのアップデートを通してマザーボードベンダーから行われるため脆弱性の発見から修正までに非常に長い時間がかかりN-day Attackを容易にする等の問題があった。 これらに対し、セキュリティとして重大な問題が発生しうるため強行的に仕様の変更を行ったのではないかと推測される。

また、前述したUHD-BDの復号以外でローカルでのEnclaveを必要とするキラーアプリケーションが登場しなかった。 一方でSGXSDKの開発は複雑であり、コストの増大によってIntelが企業として採算を採るために仕様を変更したのではないかとも考えられる。 SGXの使われ方がPowerDVDのようなサーバーからローカル側へのRAから、ローカルからサーバーへのRAへと変化したというような都合もあり時代の変化に合わせた可能性も考えうる。

同様の内容について私が大学内ゼミにて発表したスライドにおいても言及したが、この内容が正しいのかどうかの決定的な自信が持てないため、本ゼミにてより深い学習を行いと考えている。 https://www.docswell.com/s/hayao/59VPEY-sgx#p35

Intelが取るべき行動

事前にIntel SGXの将来性についての方針と十分なロードマップを公開し、適切なマイグレーション期間を経て移行を行うべきであったと思う。 特にEPID-RAについては認証がIntel側に依存する等のベンダーロックインの問題があった一方で、セキュリティ的に緊急を要するものではなかったように思う。 また、SGXは単なる機能のDeprecatedに留まらず全体的にドキュメントが不足していることが指摘されている。これはRAのリファレンス実装が不足しているという指摘もあり、 ドキュメントの整備を行うべきに思う。Intel SGX Explainedは概念の説明に留まり実装について具体的な説明をしているわけではないので適切なドキュメントを整備してほしいように思う。

Q3

VM型と部分隔離型の最大の違いは隔離される粒度であり、それに伴って信用する範囲も大きく異なる。

Enclave内で動作するような小さなプログラムでは相対的に脆弱性に気づきやすいが、OSのような巨大なプログラムにおいては人間の認知能力を大きく上回るため脆弱性の発見や修正が遅れることがある。これは、未発見の脆弱性、特に攻撃者以外誰も気づいていないゼロデイ脆弱性が存在するリスクを高める。

何らかの理由(バッファオーバーフロー等)で任意コード実行の重大な脆弱性を持ったカーネルが動作しており、この脆弱性にはまだ攻撃者以外誰も気づいていないとする。この脆弱性は攻撃者が任意コードを実行できるとする。ある攻撃者Aはこれからこの脆弱性に対しゼロデイ攻撃を行う。

部分隔離型のTEEであればEnclaveの中に侵入することはできないため保護されたままである。まさにこれは特権レベルで動作するカーネルすら信用しないというIntel SGXの脅威モデルそのものである。

一方、VM型TEEの場合、その信頼境界は内部のゲストOSカーネルを含む。もしこのゲストOSカーネルに先述のゼロデイ脆弱性が存在し、VM型TEEの中で動作していたとする。この場合、攻撃者Aがこの脆弱性を悪用してゲストOSカーネル内で任意コード実行を達成すると、VM型TEEが提供する分離メカニズムを迂回し、TEE内部を攻撃者が任意に操作可能となる。これは、VM型TEEの信頼境界がゲストOSカーネルを含むために生じる脆弱性である。

TEE内部のコード量に伴い脆弱性が存在する確率も向上するため、VM型においては内部のゲストOSを安全に保つよう注意する必要がある。

Q4

Model Specific Registerとは

Intel 80386で実験的に投入され、その後Pentiumで正式に採用されたものである。 RDMSRWRMSRにより読み書きを行うことが可能であり、CPUIDによってそのCPUが持っている機能を特定できるようになった。

値の読み取り

msr-toolsに含まれるrdmsrを用いた。

hayao@Hayao-XPS9350 ~> sudo rdmsr -a 0x10A
df9fd6b
df9fd6b
df9fd6b
df9fd6b
df9fd6b
df9fd6b
df9fd6b
df9fd6b

全てのプロセッサにおいて同様の値が返された。

値の意味

アドレスビット説明
10AH0RDCL_NO: Rogue Data Cache Load (RDCL) の影響を受けない
10AH1IBRS_ALL: 強化された Indirect Branch Restriction Speculation (IBRS) をサポート
10AH2RSBA: RSB Alternateをサポート。RSBが空の場合、RET命令で代替分岐予測子が使用されることがある。retpolineを使用するソフトウェアは、この動作の影響を受ける可能性がある
10AH3SKIP_L1DFL_VMENTRY: 1の値はハイパーバイザーがVMエントリー時にL1Dをフラッシュする必要がないことを示す
10AH4SSB_NO: Speculative Store Bypass (SSB) の影響を受けない
10AH5MDS_NO: Microarchitectural Data Sampling (MDS) の影響を受けない
10AH6IF_PSCHANGE_MC_NO: プロセッサは、TLBを無効にすることなくコード・ページのサイズを変更することによるマシン・チェック・エラーの影響を受けにくい
10AH7TSX_CTRL: RTM_DISABLE と TSX_CPUID_CLEAR をサポート
10AH8TAA_NO: プロセッサーはIntel® Transactional Synchronization Extensions (Intel® TSX) Asynchronous Abort (TAA) の影響を受けません
10AH10MISC_PACKAGE_CTRLS: プロセッサーはIA32_MISC_PACKAGE_CTRLS MSRをサポートしています
10AH11ENERGY_FILTERING_CTL: プロセッサーはIA32_MISC_PACKAGE_CTLS[0] (ENERGY_FILTERING_ENABLE) ビットの設定と読み取りをサポート
10AH12DOITM: プロセッサーはデータオペランド独立タイミングモードをサポートしています
10AH13SBDR_SSDP_NO: プロセッサーはShared Buffers Data Read (SBDR) 脆弱性またはSideband Stale Data Propagator (SSDP) のどちらの影響も受けない
10AH14FBSDP_NO: プロセッサーはFill Buffer Stale Data Propagator (FBSDP) の影響を受けない
10AH15PSDP_NO: プロセッサーはPrimary Stale Data Propagator (PSDP) に関連する脆弱性の影響を受けない
10AH16MCU_Enumeration: 1の場合、プロセッサーはIA32_MCU_ENUMERATIONおよびIA32_MCU_STATUS MSRをサポートしています
10AH17FB_CLEAR: プロセッサーはVERW命令によるMD_CLEAR操作の一部として、フィルバッファ値を上書きします。これらのプロセッサーでは、L1D_FLUSHはフィルバッファ値を上書きしない
10AH18FB_CLEAR_CTRL: プロセッサーはIA32_MCU_OPT_CTRL MSR (MSR 123H) およびそのMSR内のFB_CLEAR_DISビット (ビット位置3) の読み書きをサポートしています。
10AH19RRSBA
10AH20BHI_NO
10AH21XAPIC_DISABLE_STATUS: IA32_XAPIC_DISABLE_STATUS MSRが存在すること、およびビット0がレガシーxAPICが無効化されAPICステータスがx2APICにロックされているかどうかを指定することを示す
10AH23OVERCLOCKING_STATUS: 設定されている場合、IA32_OVERCLOCKING STATUS MSRが存在する
10AH24PBRSB_NO: 1の場合、プロセッサーがポストバリアReturn Stack Buffer予測の影響を受けないことを示す
10AH25GDS_CTRL: IA32_MCU_OPT_CTRL[4] と IA32_MCU_OPT_CTRL[5] の両方のサポートの列挙です。
10AH26GDS_NO: Gather Data Samplingに対して脆弱ではない
10AH27RFDS_NO: Register File Data Samplingに対して脆弱ではない
10AH28RFDS_CLEAR: プロセッサーはRegister File Data Samplingに対して脆弱であり、VERW命令はRegister File Data Samplingの影響を受けるバッファを上書きする
10AH29IGN_UMONITOR_SUPPORT: 1の場合、IA32_MCU_OPT_CTRL[6] (IGN_UMONITOR) をサポート
10AH30MON_UMON_MITG_SUPPORT: 1の場合、IA32_MCU_OPT_CTRL[7] (MON_UMON_MITG) をサポート
10AH32PBOPT_SUPPORT: 0の場合IA32_PBOPT_CTRLビット0 (PBOPT) はサポートされていない 1の場合IA32_PBOPT_CTRLビット0 (PBOPT) をサポート
10AH62ITS_NO: 0の場合ハイパーバイザーはシステムがIndirect Target Selectionの影響を受けないことを示す 1の場合ハイパーバイザーはシステムがIndirect Target Selectionの影響を受ける可能性があることを示す
10AH63MSR_VIRTUAL_ENUMERATION_SUPPORTED: 0の場合MSR_VIRTUAL_ENUMERATIONをサポートしない 1の場合MSR_VIRTUAL_ENUMERATIONをサポート

私のPCで取得した値をマッピングすると次のようになる。マップにはecho 1101111110011111110101101011 | rev | fold -w 1を使用した

ビット
0RDCL_NO1
1IBRS_ALL1
2RSBA0
3SKIP_L1DFL_VMENTRY1
4SSB_NO0
5MDS_NO1
6IF_PSCHANGE_MC_NO1
7TSX_CTRL0
8TAA_NO1
90
10MISC_PACKAGE_CTRLS1
11ENERGY_FILTERING_CTL1
12DOITM1
13SBDR_SSDP_NO1
14FBSDP_NO1
15PSDP_NO1
16MCU_Enumeration1
17FB_CLEAR0
18FB_CLEAR_CTRL0
19RRSBA1
20BHI_NO1
21XAPIC_DISABLE_STATUS1
221
23OVERCLOCKING_STATUS1
24PBRSB_NO1
25GDS_CTRL0
26GDS_NO1
27RFDS_NO1
28RFDS_CLEAR0
29IGN_UMONITOR_SUPPORT0
30MON_UMON_MITG_SUPPORT0
310
32PBOPT_SUPPORT0
62ITS_NO0
63MSR_VIRTUAL_ENUMERATION_SUPPORTED0

それぞれのビットの意味の説明

各ビットは投機的実行に起因する脆弱性Spectreや同時期に発見されたMeltdownに対する対応状況を示している。

具体的な脆弱性とそれに対する対応状況を示すために使われているが半分以上のビットは今後のために予約されており、現在は割り当てられていない。

本レポートにおいて、作成期間中に全てのビットについて詳細な調査を行うことができず、一部のビットについてのみ自身が調べた概要を述べる。

22番目のビットについて

Intelの公式ドキュメント上では、22は特別な意味が割り当てられていなかったが私のPC(Dell XPS 9350)では1となっていた。

これは私のPCのCPUが非常に新しい(Intel Core Ultra 7 258V)ことに起因していると推測している。 既に22番目のビットは非常に新しいCPUでなにかの役割を持っている一方で、まだ正式に文書化されていないのではないかと考える。

0. Rogue Data Cache Load (RDCL)

Meltdownの影響を受けるかどうか。投機的実行機能とキャッシュサイドチャネルを悪用して、権限のないユーザーモードプロセスが機密性の高いカーネルメモリの内容が読み取られてしまう危険性のある脆弱性。

1. Indirect Branch Restriction Speculation(IBRS_ALL)

pectre Variant 2(分岐ターゲットインジェクション)に対する緩和策の1つ。低い権限で実行されているコードが、高いレベルのコードの投機的実行予測を制御できないように制限する。顕著なパフォーマンスに対するオーバーヘッドが存在する。

2. RSBA

リターンスタックバッファ(RSB)が空になった状態でRET命令が実行された際に、CPUはリターンターゲットの予測を決定するために、分岐ターゲットバッファ(BTB)などの代替予測器にフォールバックする。このフォールバック先が意図的に操作されやすく、攻撃者の意図しているアドレスにジャンプさせられる危険性がある。

3. SKIP_L1DFL_VMENTRY

Cascade Lake以降に実装された、L1DFに対するハードウェア的な緩和策。

4. SSB

Variant 4としても知られ、メモリディスアンビギュエーションと呼ばれる性能最適化メカニズムに起因する。投機的実行により書き換えが終わる前に古いメモリを読み取ってしまう危険性があり、これにより特権を持った仮想マシンやサンドボックスの値を覗ける危険性がある。

5. MDS

ZombieLoad、RIDL、Falloutとも呼ばれる。投機的実行のためにCPU内部の一時バッファが、仮に破棄されたとしても痕跡を残すことを悪用し、サイドチャネル攻撃によってその一部が読み取られる脆弱性。

6. IF_PSCHANGE_MC_NO

近年のモダンなOSやCPUはより大きなページサイス(スーパーページ)をサポートしている。 特定の状態でそのページサイズを変更すると、MAchine Check Errorが発生することがある。この挙動を悪用することで仮想マシン上でシステムダウンを引き起こす恐れがある。(CVE-2018-12207) Translation Lookaside Bufferを無効化することで回避できるが、そのかわりにパフォーマンスが悪化する。

7. TSX_CTRL

Intel Transactional Synchronization Extensionsを無効化するための機能が存在しているかどうかを示す。

この機能には脆弱性が報告されている。

8. TAA_NO

Intel Transactional Synchronization Extensionsにおいて、トランザクションが非同期的に終了した際の投機的に読み出したデータがサイドチャネル攻撃によって攻撃者に推定されてしまう脆弱性(CVE-2019-11135)の影響を受けない。

10. MISC_PACKAGE_CTRLS

ENERGY_FILTERING_ENABLEのような機能のオンオフをサポートしているかどうかを示す。

11. ENERGY_FILTERING_CTL

Intel TDXにおいて、電源に関するサイドチャネル攻撃に対しての設定をサポートしているかどうか。

参考文献

今回の文献の収集の一部にGoogle GeminiのDeepResearchを用いている。

以下はDeepResearchとNotebookLMを用いて広範囲に調査した際に用いられた資料である。全てのソースについて情報源を確認しているが、量が膨大であることと私の脆弱性に対する知識不足によって情報が適切であり間違いがないかどうかを確実に確認することはできなかった。

TsukuCTF 2025 Writeup
ハヤオの次回作にご期待ください