ESXiの透過的なページ共有 (TPS:Transparent Page Sharing)と脆弱性の研究論文

ESXiの透過的なページ共有 (TPS:Transparent Page Sharing)が学術論文の指摘でデフォルトOFFになったと聞くが、攻撃をうけるケースが分からず調べたのでメモ。
(どうやら正しくは、VM間のTPSとVM内のTPSの2パターンがあり、デフォルトOFFはVM間のTPSの模様)

公開されている学術論文では、透過的なページ共有が 2 つの仮想マシンの間で有効化されている場合、キャッシュ メモリのフラッシュとリロードを強制することにより、ホスト サーバの同じ物理プロセッサで実行している別の仮想マシンで使用される AES 暗号キーを試して決定するためのメモリ タイミングを計測することは可能であることが示されています。この技術は、VMware で本番環境では再作成されないと考えている標準以外の方法で構成された高度に管理されたシステムでのみ動作します。

https://kb.vmware.com/s/article/2080735?lang=ja


脆弱性研究論文はなかなか見つけられなかったが「Wait a minute! A fast, Cross-VM attack on AES」という論文該当しそうに見える。確かにAbstractで「Cross-VM Flush+Reload cache attacks in VMware VMs to recover the keys of an AES」と記載しているので後ほど読んで仕組みを理解したいと思う。

Abstract. In cloud computing, efficiencies are reaped by resource sharing such as co-location of computation and deduplication of data. This work exploits resource sharing in virtualization software to build a powerful cache-based attack on AES. We demonstrate the vulnerability by mounting Cross-VM Flush+Reload cache attacks in VMware VMs to recover the keys of an AES implementation of OpenSSL 1.0.1 running inside the victim VM. Furthermore, ...

Wait a minute! A fast, Cross-VM attack on AES

斜めみの範囲では以下の理由と原理で「Flush+Reload cache attacks」が成功するように理解した。

  • TPSで2つのVMのメモリーがHV上で共有状態(EPTは別だが、最終的は物理メモリーが共有された状態)になる前提
  • この時、物理メモリーが共有状態のため、CPUのキャッシュメモリーも双方のVMで共有状態になる
  • この時に1つ目のVMは該当の共有状態のメモリーアドレスのキャッシュをFLUSHし、他方のVMがメモリを書き換えるのを待つ
  • 2つめのVMがメモリーを書き換えた瞬間(実際はキャッシュメモリーのみ更新されているタイミング)を見計らって該当アドレスを参照する。この時、メモリーが書き換わっていればアクセス時間の変化が観測でき、ここから内容を推測できる可能性がある。

 

フレッツ・テレビ伝送サービスと仕組み

ずいぶん古いサービスと技術の話になるが、フレッツ・テレビ伝送サービス(フレッツの光回線を用いて、IPを用いないでテレビの信号を伝送するサービス(RF下り片方向伝送))が、何気にすごいと、あたらめて気になったのでメモ。
調べてみると、以下ブログが技術面についてまとめてくれていたが、具体的な方式は載っておらず色々調べることに。

フレッツ・テレビのしくみ - KIMUKAZU blog

最終的に以下2つの技術情報から、フレッツ・テレビ伝送サービスとは明記していないものの、「FTTH による映像配信サービスに導入されている FM 一括変換方式(中略)最近の伝送帯域拡大対応開発」、「㈱スカイパーフェクトコミュニケーションズと協力して展開している光波長多重放送」とあり、期待する情報と考えられた。

ブロードバンドアクセスと FM 一括変換光映像配信システム

https://annex.jsap.or.jp/photonics/kogaku/public/38-05-gijutsu.pdf

FTTH発展に向けた光アクセスの動向─シンプルでスマートな光アクセスネットワークの提案

https://journal.ntt.co.jp/backnumber2/0705/files/jn200705004.pdf

ざっくりポイント

  • TV(アナログ(停波済)、デジタル)の信号をFM 一括変換方式で変調し、光ファイバーで伝送する。
  • 上記TV信号(1.55μm波長)とIP通信(別波長)を1本のファイバーに載せて送る。
  • 利用者側では、ONU付近で、TV信号を分離し復調等実施することで、電波の形?で、TVに繋ぎ込むことができる。



都市計画道路 桜木東戸塚線

道路計画が策定されても開通まで時間がかかる事は多々あるが、横浜市は特に時間が掛かる印象がある。こちらの道路「都市計画道路 桜木東戸塚線」も費用問題(トンネル工事)で30年近く開通していないとのこと。

 

これだけ計画から立つと流石に見直しで中止かと思っていたら「横浜市公共事業評価委員会 」資料によると見直すが建設計画自体は続けるらしい。


都市計画道路 桜木東戸塚線 (平戸地区)

https://www.city.yokohama.lg.jp/city-info/zaisei/kokyo/jigyohyoka/r03/dourobukai.files/0027_20220125.pdf

一応、ニュースにもなっており「高度技術提案型総合評価落札方式」での工事予定となっている。

■高度技術提案型総合評価方式の手続について

http://www.nilim.go.jp/lab/peg/img/file210.pdf

 

横浜市 桜木東戸塚線、高度技術提案型で

https://www.kentsu.co.jp/webnews/view.asp?cd=220914400016&pub=1

一方、今年度に「都市計画道路桜木東戸塚線(平戸地区)街路整備工事 」の入札が予定と記載されて、「戸塚区平戸五丁目から平戸町まで、トンネル築造工一式」で工期が99ヶ月(約8年)と凄い予定になっている。インフレが進むなかで本当に予定通り施工と完成に至るのだろうか?


■横浜地区の発注見通し

https://www.ktr.mlit.go.jp/ktr_content/content/000693307.pdf

ESXi6.7でデータストア上のovaをデプロイする

vCS6.7では、[OVFテンプレートのデプロイ]メニューだと、OVAの参照先が「ローカルからアップロード」か、「URL指定」で、データストアを参照できず、困っていたが、
回避策があったようなのでメモ。結論からいうと、コンテンツライブラリを介することで実現できる模様。

  1. 一度、コンテンツライブラリ(データストアを指定)を作成し、ovaファイルをアップトードする。
  2. その後、[メニュー] > [コンテンツ ライブラリ] >[テンプレート] タブの順に移動
  3. OVF テンプレートを右クリックして、[このテンプレートから仮想マシンを新規作成] を選択
  4. 無事にデータストア上のovaをデプロイできた。


■以下,参照kb.

docs.vmware.com

init実行

久しぶりにxv6の処理を読んでいる。
コンパクトなコードでここまで処理を実装しているのは凄いの一言に尽きるが、特に気になったinitに関してメモ。

initcode.S(_binary_initcode_start)

    initcode.sは仮想アドレス0x00000000に配置されている。
    非常に単純なアセンブラ で記述されており、処理内容は以下の2つである。
    1. fs.img上のinitを実行(syscall exec)する。
    2. initcode自身を終了(sys call exit)する。

# exec(init, argv)
.globl start
start:
  pushl $argv
  pushl $init
  pushl $0  // where caller pc would be
  movl $SYS_exec, %eax
  int $T_SYSCALL

# for(;;) exit();
exit:
  movl $SYS_exit, %eax
  int $T_SYSCALL
  jmp exit

# char init = "/init\0";
init:
  .string "/init\0"

# char *argv = { init, 0 };
.p2align 2
argv:
  .long init
  .long 0
init.c(init)

    fork(sys call fork)を実行する。
    親プロセス側は子プロセスの終了待ち。
    子プロセス側はshell(sh.c)を実行する。

int
main(void)
{
  int pid, wpid;

  if(open("console", O_RDWR) < 0){
    mknod("console", 1, 1);
    open("console", O_RDWR);
  }
  dup(0);  // stdout
  dup(0);  // stderr

  for(;;){
    printf(1, "init: starting sh\n");
    pid = fork();
    if(pid < 0){
      printf(1, "init: fork failed\n");
      exit();
    }
    if(pid == 0){
      exec("sh", argv);
      printf(1, "init: exec sh failed\n");
      exit();
    }
    while*1 >= 0 && wpid != pid)
      printf(1, "zombie!\n");
  }
}

*1:wpid=wait(

MCE(Machine Check Exception) とLinuxサーバー

先日とあるLinuxサーバでMCEやERRORなる文字列がログ記録されて、幾つかのプロセスがダウンしていた。

エラー文字列から調べてみると以下記事に記載のあるメモリ故障の可能性が高そう。実際に知識としてECCエラーやMCEによるリカバリというのは頭にあったが、実際にWorkした事例を目にして少し驚いた。

参照:

PCクラスタ、1Uサーバ、スケーラブルインフラ、HA、HPCクラスタリング、Linuxのクラスターコンピューティング株式会社 - LinuxでEDACを使いECCエラーを検出する