BitVisorの開発環境(ハードウェア・ファームウェア)

BitVisorの開発環境(ハードウェア・ファームウェア)を振り返ります。

CPU

開発初期(2007)はIntel VT-x搭載のCPUだけでなく、マザーボードのBIOSがVT-xを使えないようにしているものが存在していて選択に苦労していましたが、最近ではそんなこともなくなりました。開発PCで使用していたCPUで、主要なものをあげると以下のようになります。

• Intel Core 2 Duo (型番不明)
• AMD Phenom (型番不明)
• Intel Core 2 Duo P8600 (Lenovo ThinkPad X200)
• Intel Atom Z520/Z530
• Intel Core i7 (Nehalem世代) (Panasonic Let'snote)
• Intel Core i7 (Sandy Bridge世代) (Lenovo ThinkPad X220)
• AMD FX-4300
• AMD Z-01
• Intel Core i7 4771 (Haswell世代)

Intel Atomは組込み総合技術展に出すデモ用の小型端末に搭載されていたものですが、微妙にVT-xの挙動も違う部分があったため、BitVisorにもそれに伴う改良が入っています。

Sandy Bridge世代のIntel Core i7やAMD FX-4300は、EPTなどCPUの最新機能への対応を実装する時に使用していたものです。また、AMD FX-4300のPCはUEFIへの対応作業時においても使用していたような気がします。

CPUの新機能は最近でもちょくちょくありますが、必要に応じてちょこちょこと確認しているのみで、上のリストには入れていません。EPT対応の時ほど大掛かりな新機能対応はありません。

BIOS

2012年のWindows 8の登場とともに、一気にUEFIファームウェアが普及してきたため、最近はBIOS環境で試すことも少なくなってきましたが、いくつか癖のあるBIOS環境がありました。特に印象に残っているのは以下の2つです。

• Lenovo ThinkPad X200
• Lenovo ThinkPad X220

X200では、AHCIに設定していても、Disk BIOSはATA互換のアクセスを使用します。そのためBitVisorのストレージ暗号化ではATAとAHCIの両方に対して同じ暗号化設定を使う必要がありました。

X220では、Disk BIOSはSMMを用いた裏口アクセスを使用します。SMIを発行するI/O命令を実行すると、次の命令に来た時にはデータ転送は完了しており、I/O命令なのになぜかフラグレジスターなどが変化している、というような挙動だった気がします。さすがにこれは機種依存のためBitVisorのストレージ暗号化では対応していません。

UEFI

UEFI(Apple EFIを含む)についても、BitVisorと直接関係はないものが多いですがトリッキーな話があります。

• Apple iMac 2011頃
• Apple iMac 2014
• Apple Mac mini 2018
• 富士通
• HP
• Lenovo

2011頃のiMacはちょっと変で、ブートエントリを登録する際のDevice PathにPCIデバイス等のアドレスから記述するとなぜか起動時に30秒止まるという事象がありました。また、fast bootっぽい仕掛けがあったようで、OS XからblessコマンドでHFS+上においたEFIアプリケーションの起動を設定して、そこからWindowsやGNU/Linuxを起動すると、画面の明るさが変えられないという事象もありました。

2014のiMacは比較的素直なほうだと思います。BIOS環境が残っているのはここまでです。これともう少し後のモデルまでは、確か、グラフィックスモードにしているとOutputString()の文字列が画面に表示されません。

2018のMac miniはANS2の関係か、何かいろいろ変な問題を抱えています。ファームウェアのNVMe driverをdisconnectしようとすると、失敗してしまいます。これはどうやら、中で使われるUninstallMultipleProtocolInterfaces()の引数が間違っているために失敗しているのが原因のようです。他にも、ファームウェアのQueryVariableInfo()が無効命令を実行してしまい、LinuxからEFI variableの書き換えができないという話もあるようです。EFI Shell v2がハングするというのもあったかも知れません。さらに、Broadcom NIC内蔵機にThunderbolt Ethernetアダプターを接続した場合、ファームウェアが認識するMACアドレスがなぜかどちらのNICも同じになってしまうということもありました。

富士通機はなぜかファームウェアがJIS配列キーボード設定で動きます。おかげでバックスラッシュが入力できないんだったか、パイプ記号が入力できないんだったか、詳しくは忘れましたが微妙な問題があります。US配列のキーボードしかなければもっと困ることになります。あと、ブートエントリを置き換えたはずなのに追加されているというような事象があって、それはセットアップ画面で何か設定を変更しないといけなかったはずです。

HPのファームウェアも、古いモデルではひどいものがあって、ブートエントリの設定が完全に無視されていました。Linuxにしても何にしても、標準でないエントリから起動したい場合は、毎回ブートメニューを出すか、あるいは、セットアップ画面で手動でエントリを入れる必要がありました。後のWindows 10の頃のモデルではこういう不思議な問題は解消されています。

Lenovoも独特で、何かの拍子に勝手にWindowsを起動するエントリが登場するモデルや、EFI variableからBoot####をすべて消して自分のブートエントリだけを入れると、再起動時にCMOSの設定が壊れているなどとエラーが出て初期設定にリセットされてしまうモデルがあります。

VT-d

DMAR pass-throughの開発や検証に使った環境がいくつかあります。

• Lenovo ThinkPad X200
• Lenovo ThinkPad X240s
• Apple iMac 2014
• Apple Mac mini 2018

X200はCore 2 Duo世代のPCで、VT-dはありますが、アドレス変換のみで割り込みremappingがありません。

X240sは割り込みremappingもあり、x2APICも使われます。

Apple機はファームウェアがVT-dを有効にしています。設定を読み込んでダンプしてみた感じでは、アドレス変換はアドレス自体は変更ないのですが、無関係なアドレスはアクセスできないようにしているように見えます。また、割り込みremappingについては確か有効になっていて、特にMac mini 2018ではひとつだけremappingエントリがあって、タイマー割り込みがHPETになっています。(I/Oアクセスを試した感じではPC互換のレガシーデバイスがなくなっていたはずです。) BitVisorのCONFIG_DISABLE_VTD=1は、アドレス変換をすぐに無効にしますが、割り込みremappingはExitBootServices()の時までは無効にしないという仕掛けが入っているのは、このHPETのタイマー割り込みが引き続き発生するようにするためです。