FFRIエンジニアブログ

ＦＦＲＩセキュリティのエンジニアが執筆する技術者向けブログです

トップ > セキュリティ > SMM ルートキット入門

SMM ルートキット入門

セキュリティ マルウェア マルウェア-攻撃手法

はじめに

基礎技術研究部の松尾です。

マルウェアの中でも特に強力なものとして、カーネルルートキット、ハイパーバイザールートキット、UEFI ブートキットなどが挙げられます。 しかし、これらを上回る強力さを持つ (持っていた) マルウェアとして、System Management Mode (SMM) ルートキットがあります。

本記事では、SMM の基本を紹介した上で、SMM ルートキットの仕組みや脅威について解説します。 また、SMM が弱体化されつつある現在の動向を踏まえ、SMM ルートキットが今の PC にどれくらい通用するのかも解説します。

SMM の基本

CPU にはいくつかの動作モードがあり、SMM は x86 アーキテクチャにおける CPU モードの 1 つです。

CPU モードは、CPU がどの命令を実行できるか、どのメモリ領域にアクセスできるかなどを分けるために存在します。 例えば、ある CPU に 48 89 C8 という機械語を Long Mode で実行させる時と Protected Mode で実行させる時とで、命令の解釈は以下のように変わります。

  • Long Mode: mov rax,rcx (48 89 C8)
  • Protected Mode: dec eax (48); mov eax,ecx (89 c8);

また、ハイパーバイザーを実行する時は CPU が VMX Root Mode に切り替わって vmread/vmwrite 命令などの VM を管理する命令が使えますが、仮想マシン上のコードを実行する時は VMX Non-Root Mode に切り替わるので vmread/vmwrite 命令などは使えなくするといった用途もあります。 皆さんが PC で普段作業をしている際、基本的に CPU は Long Mode で動いています。

SMM とは、電源管理や大事なハードウェアの制御などを行うための CPU モードです。SMM 中は全てのコアが SMM で動作し、割り込みも基本全てブロックされます。 CPU は SMI (System Management Interrupt)*1 という割り込みを受け取ることでのみ SMM に移行し、その後 rsm 命令が実行されると元のモードに戻ります。 CPU が SMI を受け取ると、SMM Entry という決められたコードを実行します。SMM Entry では、SMM に入る前のレジスタの退避や SMM 専用のページテーブルの設定などが行われます。その後、SMI に載せられたコマンド番号に応じて SMI ハンドラーが実行されます。 SMI ハンドラーは、BIOS モジュールの一種である SMM モジュールに定義されています。 SMM モジュールは、PC のブート中、厳密には UEFI の DXE フェーズにてインストールされます。 SMM Entry や各種 SMM モジュールは SMRAM という特殊なメモリ領域にロードされます。

SMM の全体像

SMRAM は、具体的には TSEG (Top Segment) もしくは CSEG (Compatibility Segment) というメモリ領域のどちらかになります。 現代の PC では TSEG が SMRAM として使われる事が多いため、以降その前提で書きます。 SMRAM のアドレス範囲は、ホストブリッジの PCI レジスタである Top Segment Memory Base (TSEGMB) のアドレスから、Base of Graphics Stolen Memory (BGSM) のアドレスまでです。 この領域は、SMM 以外の CPU モードからは読み書きできないよう、SoC がハードウェアレベルで制限しています。

SMRAM は TSEG 全体を表す場合と、各コアが認識しているそれぞれの TSEG の部分領域を表す場合があります。本記事では前者を広義の SMRAM、後者を狭義の SMRAM とします。 直前の段落で話した内容は広義の SMRAM の話です。 狭義の SMRAM は、ホストブリッジではなく CPU コアの Model Specific Register (MSR) である IA32_SMBASE のアドレスをベースとしたメモリ空間です。 SMM から戻る際、各コアは SMM に入る直前のレジスタ値をこの狭義の SMRAM に保存します。 各コアはそれぞれが違う処理を実行しているため、レジスタ値をコア毎に分けておく必要があり、狭義の SMRAM はコア毎に用意されています。 SMM Entry も狭義の SMRAM にあり、ここではそのレジスタの退避処理と、SMI ハンドラーに処理を遷移させるといった事を行います。

より詳細を知りたい方は、Intel の仕様書を参照して下さい。 狭義の SMRAM や、SMM 中のコード実行の制約などについては Intel Software Developer Manuals (SDM) を参照して下さい。 広義の SMRAM については、CPU の各種ブランド (Pentium とか Celeron など) のデータシートを参照して下さい。例として、調べたい PC の CPU が Intel Atom® Processor E3900 Series であれば、このデータシートを参照するといった感じです。

SMM の脅威

SMM を悪用する事により、攻撃者が得られるメリットは主に以下 2 つです。

  1. クラウドを侵害するパワー: ハイパーバイザーベースのセキュリティを突破できる
  2. 圧倒的なステルス性: OS から検知することがほぼ不可能になる

1: クラウドを侵害するパワー

1 つ目は、OS 起動後に別の CPU モードでコード実行できるという SMM の性質を悪用するメリットです。

クラウドのセキュリティを支えているのは、ハイパーバイザーによる VM 間の分離です。そして、その分離を実現しているのは、CPU によるページングと仮想化用のモードです。

  • ページング: ある VM1 が VM2 にアクセスできないのは、ハイパーバイザーが管理する VM1 のページテーブルに VM2 のページがマップされていないからです
  • CPU モード: VM がハイパーバイザーの設定等を改ざんできないのは、VM は (Intel の場合) VT-x non-root mode で動作していて設定をいじる命令が使えないからです

しかし、CPU が SMM に移行すると、SMM 用のページテーブルが使われるため、ハイパーバイザーの影響無く、全ての物理メモリにアクセスできます (後述する SMM の特権剥奪がされていなければ)。ハイパーバイザーのメモリにも直接アクセスできるため、ハイパーバイザーの設定を改ざんする必要もなくなります。

したがって、攻撃者は SMM を使えば、どの VM にも、あるいはハイパーバイザーのメモリにもアクセスが可能になります。

SMM ルートキットではなく、カーネルルートキットや UEFI ブートキットを用いる場合、クラウドを侵害するのは困難です。
カーネルレベルのコードは、ハイパーバイザーにより分離されているため、他の VM やハイパーバイザーのメモリを操作できません。
OS 起動後に動作可能な UEFI モジュールは、SMM モジュール以外だとランタイム DXE モジュールのみですが、これも OS 起動後はカーネル空間にマップされています。 故に、マップされた VM 以外の VM のメモリ等にはアクセスできません。

ただ、UEFI ブートキットはブート中にハイパーバイザーを改ざんする事で、ハイパーバイザーベースのセキュリティを突破する事はできます*2。とはいえ、BIOS が格納されている SPI フラッシュに書き込める状況下にて、わざわざこれをバイパスする UEFI モジュールを入れるくらいなら、SMM モジュールを入れた方が攻撃は楽かつ強力です。

2: 圧倒的なステルス性

2 つ目は、SMM の挙動や存在は SMM 以外の CPU モードで動作するカーネル等から見えないという性質を悪用するメリットです。

見えないとは具体的に、以下 2 つの意味です。

  • SMM のコード実行を観測できない: 観測するにはコード実行中に割り込んで観測側 (OS 等) の処理に回す必要があるが、SMM 中は割り込めない
  • メモリ上で存在を確認できない: カーネルやハイパーバイザーは SMM で動作できないため SMRAM の内容が見えず、メモリダンプ等ができない

したがって、攻撃者は SMM を使えば、OS やハイパーバイザー等から悪性挙動を観測される危険性がほぼ皆無になります。

SMM ルートキットではなく、カーネルルートキットや UEFI ブートキットを用いる場合、攻撃の痕跡をこのレベルで消すのは困難です。
カーネルレベルのコードとランタイム DXE モジュールどちらも、カーネルメモリをダンプすれば存在は確認できます。静的に解析せずとも、メモリ上でこれらのコードのどこかで割り込みを発生させれば、検査用のコードを途中で走らせる事も可能です。

SMM ルートキット

SMM で動作するマルウェアである SMM ルートキットについて紹介します。

SMM ルートキットが実世界で実際に使われたという報告は、少なくとも私の知る限りでは一件もありません。以下は、研究における PoC や、国の諜報機関からリークしたとされるドキュメント (Vault7 等) からかき集めた SMM ルートキットの一覧です。

年 ルートキット名 概要
2008 キーロガー (通信機能付き) キー入力の割り込みハンドラーで SMI を発行し、SMI ハンドラーから NIC を直接操作してキー入力を送る
2008 DEITYBOUNCE SMI ハンドラーから OS 上で動くマルウェアにカーネルをパッチしたりするような隠蔽工作用の機能を提供
2008 IRONCHEF WAGONBED というハードウェアインプラントと通信する際に SMM を用いる
2014 USB キーロガー USB ホストコントローラーの割り込みを SMM にルートする機能を悪用し、キー入力を取得
2015 LightEater GEN_PMCON_1 レジスタで周期的に SMI を発生させてメモリをスキャンし、機密情報を探索する
2016 VBS バイパス 1 SMM からハイパーバイザーの vmexit ハンドラーをフック
2017 VBS バイパス 2 SMM からハイパーバイザーのメモリを改ざん
2017 LONGKIT SMM ルートキットが様々な BIOS で動くための汎用フレームワーク
2021 Simple SMM Backdoor ring3→ring0 権限昇格用の SMM バックドア
2022 Windows 用ルートキット Windows のユーザーランドのプロセスの改ざんを SMM から行う
2023 SmmBackdoorNg メモリ上のあらゆる情報をダンプできる汎用バックドアで、様々な他のツールや PoC の機能が詰まっている

※ 具体的な名称のないものには便宜上の名称を付けています。

色々と種類があるように思えますが、基本的に SMM は、SMM の脅威で話した 2 つのメリットのうちいずれかを享受するために使われています。Virtualization Based Security (VBS) バイパス以外の物は全て、ステルス性を高めるために SMM を使っています。キーロギングや通信、ユーザーランドでのエクスプロイトを支援する機能を SMM でやるなどです。

SMM ルートキットの仕組みとして全体に共通する点は、SMM でやる事はメモリをただ読み書きするだけという点です。どれも結局は SMI ハンドラーでハイパーバイザーをパッチしたり、ユーザーランドのデータを改ざんしたり、機密情報をメモリから探して読んだり、割り込み関連のテーブルを改ざんしたりしているだけです。ハイパーバイザーの改ざん以外は、基本的に SMM でなくても出来る事で、SMM でしか出来ないことをしているというよりは SMM でコード実行した方がステルスだから、という物が多いです。

SMM ルートキットの実装において差異や特徴が出てくるのは、以下の 2 点においてです。

  1. どうやって SMM ルートキットに制御をまわすか
  2. どうやって SMM のコードから機密データを特定するか

1. どうやって SMM ルートキットに制御をまわすか
SMM ルートキットの実体は SMI ハンドラー (SMM モジュール) なので、制御を回すには SMI を発行すれば良いです。正規プログラムの実行中に SMI を発行させる方法は様々あり、そこがルートキット間の主な差別化要因となります。 例えばキーロガーであれば、キー入力の度に SMI を発行させたいので、I/O の割り込みハンドラーを改ざんして SMI を発行させる方法があります。一方で、定期的にメモリをスキャンして機密情報を抜き取りたい場合は、SMI を周期的に発行させるようハードウェアを設定する (GEN_PMCON_1 レジスタなど) といった全く別の方法が取られます。

2. どうやって SMM のコードから機密データを特定するか
SMM の不便な点として、OS の API 等を使えないという点があります。したがって、OS の API で簡単に行える通信やキー入力の取得などの操作も、直接ネットワークカードのレジスタを操作したりなど行わなければなりません。また、機密データや OS 等の重要な構造体をメモリ上で特定する際も、API を用いて OS に教えてもらう事ができません。ステルス性を少し妥協し、OS 等のコードをパッチしてデータを抜き取るか、最悪パターンマッチで探す必要があります。

SMM ルートキットの防御手法に関してですが、SMM モジュールもセキュアブートの対象です。セキュアブートは感染を防止するための機構ですが、SMM からの攻撃を防ぐ機構で重要なものとして、SMM の特権を剥奪する機構が存在します。

SMM ルートキットの感染手法

SMM モジュールは SPI フラッシュチップに書き込める状況下でないとインストールできません。
UEFI ブートキットの感染方法は主に SPI 感染型と ESP 感染型の 2 つありますが、SMM ルートキットは SPI 感染型のみに対応しています。 この 2 つ以外にも、Option ROM と呼ばれる PCI デバイス上のメモリから UEFI ブートキットを入れる事ができますが、SMM ルートキットはこれに入れられません。

SPI フラッシュへの書き込みは、SPI コントローラーのレジスタで管理されています。 具体的なレジスタ名は SoC や新旧によって微妙に異なり、「BIOS Control」や「BIOS_CNTL」という名前で各種 CPU のブランド毎の仕様書に記載されている事が多いです。 本記事では統一して BIOS_CNTL レジスタと呼びます。 名前は違えど仕組みは共通していて、BIOS_CNTL レジスタには以下のビットがあります。

  • Write Protect Disable (WPD): 1 => 0 になると SPI フラッシュへの書き込みができなくなる
  • Lock Enable (LE): 1 の時、WPD を 0 => 1 にしようとすると SMI が発行される
  • Enable InSMM.STS (EISS): 全プロセッサが SMM でない限り、SPI フラッシュへの書き込みを禁止する

ブート中、WPD=0, LE=1 にしてから OS を起動します。これにより、OS 起動後にカーネル権限のコードで SPI フラッシュに書き込もうとしても、WPD=0 なので書き込めません。 書き込めるようにするため、WPD を 0 => 1 にすると、LE=1 なので SMI が発行され、一般的にはその SMI ハンドラーが WPD を 0 に戻す事で、WPD=1 に出来なくしています。 何故単に OS 起動後は WPD=0 に固定しないかというと、BIOS アップデートを行う場合、OS 起動後に SPI フラッシュへ書き込めるようにする必要があるためです。 SMI ハンドラーからは SPI フラッシュへ書き込めるようになっています。

SMM ルートキットを SPI フラッシュに感染させるためには、以下の方法が考えられます。

  1. BIOS_CNTL レジスタの設定ミスを探す
  2. BIOS_CNTL レジスタが設定される前に書き込む

BIOS_CNTL レジスタの設定ミスを探す
BIOS が設定ミスで LE=1 にせず OS を起動している場合があります。 その場合は OS 起動後でも普通に SPI フラッシュへ書き込み可能です。 昔はこの設定ミスが多く見つかっていたのですが、最近の PC ではミスは非常に少なくなってきています。

BIOS_CNTL レジスタが設定される前に書き込む
LE=1 で SPI フラッシュへの書き込みがロックされるのはブート中の出来事で、最初からロックされているわけではありません。 ゆえに、ロックされる前の早いブート段階では SPI フラッシュへの書き込みは可能です。 とはいえ、OS 起動後の端末にて SMM ルートキットを入れたいケースがほとんどです。 したがって、現実的には OS 起動後に、ブートの初期フェーズで任意コード実行をする必要があります。 これを可能とする攻撃として、S3 BootScript 攻撃があります。 こちらは、おまけ 1 のセクションで解説します。

SMM の特権剥奪

近年のプラットフォームでは、SMM は権限が弱体化されており、SMM ルートキットのほとんどは機能しなくなっています。 この動きを SMM Deprivileging (直訳: SMM の特権剥奪) あるいは SMM Isolation と言います。

厳密には、SMM の特権剥奪は SMM ルートキットの対策のために作られた仕組みではありません。正規の SMI ハンドラーに脆弱性があった場合、そこからのエクスプロイトを最小限に抑えるための機構です。しかし、仕組みとして SMM ルートキットの対策にもなっているため、ここで紹介しています。

SMM を使った攻撃は、基本的にどれも SMM からユーザーランド/カーネル/ハイパーバイザー (以降、Non-SMM と呼ぶ) のメモリの内容を書き換える方針を取っています。 しかし、SMM で行う本来の処理では、Non-SMM のメモリ領域にアクセスする必要がありません。故に、SMM からこれらのメモリ領域にアクセスできなくしても、本来の SMM の挙動には全く支障がありません。

では、どうやって SMM から Non-SMM メモリへのアクセスを禁止するかですが、この方法は長きにわたり様々な議論がされてきました。以下、Intel に限った内容ですが、SMM 特権剥奪の進化の概要です。

  1. 2015 年: SMI Transfer Monitor (STM) が誕生したが複雑すぎて誰も使わなかった
  2. 2017 年: Intel Runtime BIOS Resilience (IRBR) で SMM のメモリアクセス可能範囲を制限
  3. 2018 年: Intel System Security Report (ISSR) で OS やユーザーに SMM が改ざんされない旨を安全に報告する術が確立
  4. 2019 年: Intel System Resources Defense (ISRD) で SMM のハードウェアへのアクセスが制限

IRBR と ISRD

これら全てに共通する大事な考え方として、SMM モジュール (SMI ハンドラー) は信頼できないが、SMM Entry は信頼するという点があります。 SMM Entry は Intel だけが実装する物なので、Intel の署名がついており、SMM Entry は改ざんされてない前提で作られています。 一方で、SMI ハンドラー (SMM モジュール) は Intel のみならず、各種 OEM やユーザーが入れられます。 したがって、SMI ハンドラーからは Non-SMM メモリにアクセスできなくするという機能です。 SMM Entry などの Intel のコードから Non-SMM にアクセスできるのは設計ミスではありません*3。

1: STM
SMM 内でハイパーバイザーを別途用意し、SMM モジュール (SMI ハンドラー) をその VM 内で動かす事で、SMI ハンドラーから Non-SMM メモリへのアクセス等を制限する物です。 今は使われてないので詳細は割愛します。

2: IRBR
SMM モジュール (SMI ハンドラー) で使うページテーブルに Non-SMM のメモリ空間をマップしないという方式です。簡単に聞こえますが、ページテーブルを SMI ハンドラーから変更できないようにするのが味噌です。SMM Entry で CR0 や CR3 レジスタ (ページングをいじれるレジスタ) をハードウェアレベルでロックしてから SMI ハンドラーに制御を渡すようにしています。

3: ISSR
これはトラステッド・コンピューティング絡みの話であり、ルートキットの攻撃を防止するのには直接関係はないため割愛します。

4: ISRD
SMM を用いたキーロガーでは、キー入力をネットワーク上に送信するためネットワークカードのレジスタを直接いじっていました。しかし、本来 SMM では全ての I/O にアクセスできる必要はないため、アクセスできるハードウェアリソースも制限するのが ISRD です。

これら機能が載っている PC では、SMM ルートキットが仕込まれたとしても、この特権剥奪機構がバイパスされない限り、ルートキットはほぼ何もできません。 OS のメモリから機密情報を盗むことも、それをネットワーク上で送る事もできません。

最近 (2026 年現在) の PC では、ビジネス用の Intel "vPro" が載った物であれば、体感半分くらいの PC で SMM の特権剥奪機構が有効になっています。 ただし、この機能の実装状況は PC メーカーやブランドによって異なります。 また、同じメーカーでもビジネス用の vPro でない製品にはこの機能は載っていません。

SMM ルートキットをリスクとして捉えるなら、この特権剥奪機構の有無を確認してみてください。 購入する PC の CPU を調べ、それが例えば Core i5-1345U であればその仕様を見ることで確認できます。 直接 SMM 保護のように書かれていない場合もありますが、その場合は「ハードウェア・シールド」が有効かを調べてみて下さい。 有効であれば特権剥奪機構もある事が多いです。

おわりに

今回は、SMM ルートキットの目的や仕組みについて紹介しました。また、SMM の権限剥奪により、これまでの SMM ルートキットの大半は通用しなくなっている事も説明しました。しかし、権限剥奪機構はどの PC にも実装されているわけではありません。この機構が無い場合、SMM ルートキットは未だ大きな脅威となるため、是非 PC を選ぶ時はこの機構の有無を確認してみて下さい。



(おまけ1) S3 BootScript 攻撃

前提知識として、(1) S3 スリープ、(2) S3 BootScript、(3) SMMの初期化 について説明した後、S3 BootScript 攻撃の仕組みについて説明します。 さらに、S3 BootScript 攻撃の防御手法についても説明します。 S3 BootScript 攻撃は SMM ルートキットのみならず、あらゆる UEFI ブートキットを SPI フラッシュへ感染させるのに使える手法です。

(1) S3 スリープ

一概にスリープといっても、S0, S1, ... など、どのハードウェアの電源は落とすかなどの観点で種類が色々あります*4。 その内、S3 スリープはメモリ以外の電源を落とすという挙動になります。

(2) S3 BootScript

S3 スリープから復帰する際、メモリ以外の電源をつけ直すため、CPU 視点だと PC 再起動と同じです。 BIOS がブート中に行う主な作業はデバイスの初期化ですが、スリープ復帰時にこれを行ってしまうと、スリープ前のデバイス設定が失われてしまいます。 また、単純にスリープ復帰のたびに同じブートパスを辿るのもオーバーヘッドが大きいです。

そこで、スリープ前のデバイス設定を戻すコードである S3 BootScript をメモリに置いておきます。スリープ復帰時に BIOS がこれを実行する事で、デバイスの設定をスリープ前の状態に戻す事ができ、かつその分ブート時間を短縮できます。

(3) SMM の初期化

SMM を使うためには、SMM Entry や SMI ハンドラーを SMRAM にロードしないといけません。 しかし、最初から SMRAM、すなわち TSEGMB-BGSM の領域が SMM 以外からアクセスできないと、SMM を初期化したいのに SMRAM にアクセスできないという事になります。 なので、最初は非 SMM でも SMRAM にアクセス可能で、SMM の初期化が終わってから SMRAM を有効化します。 具体的には、TSEGMB 等と同じく、ホストブリッジのレジスタのあるビットを立てると、TSEGMB-BGSM の領域が非 SMM からアクセスできなくなります。

S3 BootScript 攻撃の仕組み

SPI フラッシュへの書き込みを制限しているのは、SPI コントローラーの BIOS_CNTL レジスタでした。 BIOS_CNTL レジスタは最初から SPI フラッシュへの書き込みを制限しているわけではなく、ブート中のどこかのタイミングで WPD=0, LE=1 を設定していました。 S3 スリープを行うと、SPI コントローラーの電源は落ち、BIOS_CNTL レジスタの内容はクリアされます。そして、スリープ復帰時に S3 BootScript が実行されるタイミングは WPD=0, LE=1 が設定される前、つまり SPI フラッシュへ書き込めるタイミングになります。

したがって、攻撃者は以下の方法で SPI フラッシュに UEFI ブートキットや SMM ルートキットを書き込めます。

  1. S3 スリープ前にメモリ上の S3 BootScript を改ざんし、SPI フラッシュへマルウェアを書き込むコードを入れる
  2. S3 スリープさせる (ここで BIOS_CNTL もリセットされる)
  3. S3 スリープから復帰して S3 BootScript が実行され、マルウェアが書き込まれる

S3 BootScript 攻撃の防御手法 (SMM LockBox)

スリープ前にメモリ上の S3 BootScript を改ざんできなくすればこの攻撃は防げます。 S3 BootScript はブート中に作成するものなので、本来 OS 起動後にアクセスできる必要はありません。 したがって、S3 BootScript は SMRAM に保存しておけば良い事になります。 SMRAM も OS 起動後にアクセスする必要がなく、この領域に置けば OS 起動後に読み書きができなくなるからです。 この防御手法のことを、SMM LockBox といいます。

(おまけ2) SMM のエクスプロイト対策

SMM ルートキットを SPI フラッシュにインストールせずとも、エクスプロイトして SMM で任意コード実行ができれば、同様の攻撃が可能です。ここでは、SMM のエクスプロイト手法とその対策をいくつかピックアップして解説します。

1: Tich Attack

Tich Attack

SMM 以外の CPU モードからのアクセスが禁止されている広義の SMRAM は、TSEGMB から BGSM レジスタのアドレス範囲でした。
Tich Attack は、このレジスタの値を書き換えて SMRAM を一旦縮め、元々 SMRAM だった所に独自の SMI ハンドラーを置くという攻撃です。

この対策として、TSEGMB や BGSM レジスタには、そのレジスタの内容が PC (ホストブリッジ) の電源が落ちるまで書き換えられなくする Lock ビットが備えられています。SMRAM の範囲を OS 起動後に書き換える事はないので、BIOS はブート中に SMM の初期化が終わった段階で TSEGMB や BGSM をロックします。

2: SMM Callout

SMM Callout

SMM モジュールに、SMRAM 外のコードを実行する記述があれば、それは脆弱性になります。 SMM 中で SMRAM 外のコードを実行出来れば、その SMRAM 外のコードを非 SMM の攻撃者が書き換えることで、SMM でそのコードを実行できるようになるからです。

この対策は、まさに SMM の権限剥奪がそうです。SMRAM 外のページは実行不可にして SMM のページテーブルを設定すれば良いだけです。

3: キャッシュを使った攻撃

キャッシュを使った攻撃

メモリ領域である SMRAM を書き換えられなくても、CPU のキャッシュに載った SMI ハンドラーの内容を書き換える事は SMM でなくても出来ます。 したがって、キャッシュ上の SMI ハンドラーを書き換えれば、攻撃者は SMM で任意コード実行が可能になります。

この対策として、SMRR (System-Management Range Register) という MSR があります。 具体的には、IA32_SMRR_PHYSBASE と IA32_SMRR_PHYSMASK の 2 つの MSR です。 これらを適切に設定し、SMRAM の内容をキャッシュされないようにする事で対策しています。

*1: 手軽に SMI を発行する方法として、カーネル権限で outb 0xb2,al (al に SMI コマンド番号) を実行する方法があります。プラットフォーム依存ではありますが概ね通るはずです。 ↩

*2: ハイパーバイザーのvmexitハンドラーをフックする等の手法でバイパスできます。 ↩

*3: 勘のいい人は、独自の SMM Entry を入れて署名チェックも改ざんすればいいと気づくはずです。SMM の権限剥奪機構はルートキット対策ではなくエクスプロイト対策であるためこうなっています。 ↩

*4: 詳細は Advanced Configuration and Power Interface (ACPI) 仕様書を参照してください。なお、今 (2026 年現在) のほとんどの PC は、スリープは S0 となっています。powercfg /a を powershell で実行して確かめられます。 ↩