Security / SMM / Firmware

SMMアーキテクチャの全体像

SMM、SMI、SMRAM/MMRAM、Save State、lock timing、firmware debug flowを実務目線で整理します。

更新 約 4 分
Đọc bằng 日本語 Tiếng Việt English
Security / SMM / Firmware cover

SMM、System Management Modeは、CPUの特別な実行モードです。SMIが発生すると、CPUは現在のcontextを一時停止し、register stateをsave stateに保存し、保護されたmemory内でfirmware handlerを実行して、最後にRSMで元のcontextへ戻ります。

SMMを単なる強いinterrupt handlerとして見ると、debugでは見落としが出やすくなります。実務では、SMMはfirmwareのruntime islandだと考える方が自然です。boot中に構築され、OSへ制御が渡る前にlockされますが、OS起動後もSMIによって再び実行されます。

この性質により、SMMはvariable service、flash protection、power event、thermal event、chipset policy、OEM serviceなどに使われます。一方で、SMMの不具合はOS側から見えにくく、hang、reset、latency spike、SetVariable()失敗、runtime commandの無応答として現れることがあります。

boot flowの中でのSMM

SMMはPEI、DXE、BDSのような直線的なphaseではありません。PEI/DXEでmemory、CPU state、SMM Core、SMM driverを準備し、その後lockされたruntime environmentとして残ります。

簡単な流れは次のようになります。

PEI/DXE setup
  -> reserve SMRAM/MMRAM
  -> load SMM Core and SMM drivers
  -> register SMI/SMM handlers
  -> signal EndOfDxe / SmmReadyToLock
  -> close and lock SMM resources
  -> OS runtime can still trigger SMI

SMMをdebugするときは、handlerがlock前に登録されたか、そしてSMI発生時にdispatcherがそのhandlerを見つけられるかを分けて確認します。

SMI発生時の基本フロー

典型的なSMI pathは次のようになります。

SMI source
  -> CPU enters SMM
  -> CPU saves register state
  -> SMM Core runs inside SMRAM/MMRAM
  -> dispatcher finds registered handler
  -> handler validates input and handles request
  -> handler clears source/status if needed
  -> RSM returns to previous context

SMI sourceには、software SMI、GPIO/chipset event、power event、thermal event、periodic SMI、SMM communication pathなどがあります。Software SMIでは、save stateがcaller、command、register contextを調べる重要な手がかりになります。

主な構成要素

要素役割debugの見方
SMI sourceCPUがSMMへ入った理由enable bit、status bit、command IDを見る
Save StateSMI前のregister snapshotSW SMI、I/O trap、exceptionのdebugに使う
SMRAM/MMRAMSMM code/data用の保護memoryOS/DXE由来のpointerは必ずvalidateする
SMM CoreManagement Mode内のruntime coreload timing、dispatcher、handler databaseを見る
SMM Handlerrequest/eventを処理するcodebuffer、size、command、policyをvalidateする
SmmReadyToLockSMM setupのlock pointhandler登録が遅いとここで問題化しやすい

覚えておきたい不変条件

SMM sourceを読むときは、次の前提を崩さないことが重要です。

  • lock後、SMM外のcodeがSMRAM/MMRAMを変更できてはいけない。
  • handlerはOSやDXE runtimeから渡されたdataを信頼してはいけない。
  • communication bufferはaddress、size、alignment、overlapを検査する必要がある。
  • handlerは短く、boundedにし、ExitBootServices()後にBoot Servicesへ依存しない。
  • 危険なdebug/factory commandはruntime前に無効化またはpolicyで制限する。

Communication buffer内のpointerをvalidateせずに信頼する場合、それは単なる安定性のbugではなく、security boundaryの問題になります。

実際のdebug例

OS toolがfirmware serviceを呼び、settingを書き換えようとしてgeneric errorだけが返るとします。この場合、最初からBIOS Setup UIを見るより、次のchainを追う方が有効です。

OS tool
  -> Runtime Service or SMM Communication
  -> CommBuffer validation
  -> SW SMI or communication handler
  -> SMM policy check
  -> variable or flash backend
  -> status returned to caller

handlerが動いていないなら、SMI source、command ID、registration timingを確認します。handlerが動いているのに失敗するなら、buffer validation、policy lock、variable attribute、flash lock、SmmReadyToLock stateを確認します。

source readingで見るポイント

  • SMM driverはbuildされ、正しいFVに入っているか
  • MODULE_TYPEはDXE_SMM_DRIVERまたは相当するtypeか
  • handlerはentry pointで登録されるのか、notify event後か
  • handler登録はSmmReadyToLockの前か後か
  • communication bufferをvalidateするhelperは何か
  • SMRAM/MMRAMとのoverlapをrejectしているか
  • SMI source/statusを正しくclearしているか
  • debug/factory commandはruntime前に閉じられているか

残しておきたいlog

SMM debugではlogが少なすぎるとtiming問題を見落とします。最低限、次を確認できるようにします。

  • SMM driver entry pointが実行されたか
  • handler registration status
  • SMI command、source、status
  • communication buffer addressとsize
  • validation result
  • policy state: locked、unlocked、debug/factory allowed
  • variable、flash、chipset accessのbackend status
  • 最終return status

key、password、private variable payload、secure bufferの中身など、sensitive dataはlogに出さないようにします。

SMM review checklist

不安定なSMM pathをreview/debugするときの確認項目です。

まとめ

SMMは単なるinterrupt handlerではありません。独自のmemory、dispatcher、policy、security boundaryを持つfirmware runtime environmentです。debugではtrigger、handler registration、policy/backend executionを分けて見ることが大切です。

この記事が役に立ったら

ファームウェア、BIOS/UEFI、組み込みシステムを学んでいる人に共有したり、作者を応援したりできます。

ご意見

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Ghi chúFirmware Flow

Runtime Phaseとは何か

UEFIのRuntime Phaseを、OSが制御を受け取った後も残るfirmware機能として説明します。

Ghi chúBIOS Terms

System Management Interrupt (SMI)とは

SMIはCPUをSMMへ遷移させ、ファームウェアのハンドラーを実行させる特別な割り込みです。レイテンシーやSMI stormの調査で重要です。

Ghi chúBIOS Terms

System Management Mode (SMM)とは

SMMはOS通常実行から隔離されたfirmware用CPU modeです。hang、flash失敗、variable処理、security policyのdebugで重要です。

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác