Android Verified Boot
ここではAndroid Verified Boot 2.0(AVB)についてまとめる。
AVBはAndroidがOS起動前にブートローダーで行う検証機構で、Androidが不正に書き換えられていないかのチェックを行う。
仕組み
まずAndroidにvbmeta構造体を用意し、vbmetaパーティションに書き込む。vbmeta構造体は、他のパーティションのダイジェスト(ハッシュ値)を保存してある。
ブートローダーは、起動時にvbmetaを読み込み、各パーティションに改変がないかチェックする。その後、問題がなければbootパーティションからカーネルを起動しAndroidを開始する。
ちなみにvbmeta自体もベンダーにより署名されており、ブートローダーはvbmetaに有効な署名がないと起動を失敗させる。ブートローダーをアンロックするとこのvbmetaが改変されていても受け入れるようになる。
つまりブートローダーアンロックはブートローダー→vbmetaのトラストチェーンの切断といってもいい。
カスタムROM
以上の理由により、ほとんどのカスタムROMはvbmetaを同梱して配る必要がある。
GSIをsystem.imgに書き込む場合は、vbmetaを事前に作ったり配布できない。そのため、GSIを書き込む前にfastboot --disable-verity flash vbmeta vbmeta.img とかでavbを無効にする旨をvbmetaに書き込んであげないといけない。
vbmeta_hoge
vbmeta_systemとかvbmeta_vendorというパーティションがある。
最近のAndroidはsystemパーティションやvendorパーティションを物理的なパーティションにせずに、superというパーティションの中に論理的なパーティションとして置く設計になっている。(LinuxのLVMらしい)
ブートローダーはLVMを認識できないので、もちろんvbmetaによるsystemパーティションの検証が行えない。よって、vbmeta_systemにsystemパーティションのダイジェストを置き、起動時にはvbmeta_systemを検証することで、トラストチェーンの結果systemパーティションの改変を検知できるらしい。
ちなみにこのvbmeta_hogeをブートローダー起動後に誰が検証しているのかはわからない。カーネル?
dm-verityについて
dm-verityもカーネルがsystemパーティションの改変を検知する機構であり、現在も利用されている。 しかしカーネル起動以前に先にAVBに引っかかるはずなのでdm-verityが反応することはほとんどない。
参考: