Backdoor!! vmware-tools と統合サービスに見るハイパーバイザの呼び出し方

Backdoor !!
vmware-tools と統合サービスに見るハイパーバイザの呼び出し方
2010/4/12
VTCライトニングトーク発表内容
しろやまたかゆき<shiro.t@gmail.com>

Hypercall とは？
l ゲストOS からハイパーバイザを明示的に呼び出す方法
l Binary Translation や VMEXIT/VMRESUME に比べコストが低い
l 呼び出し方法が低コスト
l ハイパーバイザに都合のいいデータのやり取りが可能
l 準仮想化された OS で使用されている
l Xen 対応の Linux カーネルなど

Xen での Hypercall の実装
l 単純に int 命令でソフトウェア割り込みをかけているだけ
l Ring0 の Xen hyper-visor が割り込みをキャッチし、指定のルーチンを
呼び出している
http://www.ylug.jp/download/hypercall_ylug_20061027.pdf

Hypercall は準仮想化だけのもの？
l いえ、類似/同等の機能は完全仮想化のハイパーバイザにもあります！
l 性能上の理由
l Binary Translation や VMEXIT/VMRESUME に比べコストが低い
l 仮想化ならではの機能の実現
l VM間 / VM-Hypervisor 間の通信や制御 (VMCI)

例： VMCI
int a, s, len;
char buf[255];
struct sockaddr_vm addr = { 0 };
s = socket(PF_VSOCK_VMCI, SOCK_STREAM, 0);
addr.svm_family = AF_VSOCK_VMCI;
addr.svm_cid = VMADDR_CID_ANY;
addr.svm_rid = 2000;
bind(s, (struct sockaddr *) &addr, sizeofaddr);
listen(s, 5);
a = accept(s, (struct sockaddr *) &addr, &len);
len = recv(a, buf, sizeof buf, 0);
int a, s, len;
char *buf = “Hello, world!”;
struct sockaddr_vm addr = { 0 };
s = socket(PF_VSOCK_VMCI, SOCK_STREAM, 0);
addr.svm_family = AF_VSOCK_VMCI;
addr.svm_cid = GUEST2;
addr.svm_rid = 2000;
connect(s, (struct sockaddr *) &addr, sizeof addr);
len = send(s, buf, len, 0);
基本はソケットプログラミング
通常のPF_INETの代わりに
PF_VSOCK_VMCIに変更。
読み書き(send/recv)は変わらず
Hyper-visor
Application
Guest OS
仮想マシン
Application
Guest OS
仮想マシン
Server
Client

ESX / Hyper-V の Hypercall
l では、ESX / Hyper-V の Hypercall ってどうやってるの？
ソースコードにきいてみよう！

VMware の場合： open-vm-tools
Open Virtual Machine Tools
l vmware-tools のソースコードは公開されている (2007.9.4～)
l Linux, FreeBSD, Solaris 用
l vmsync など、標準の VMware Tools にないモジュールも存在
http://open-vm-tools.sourceforge.net/

Microsoft の場合
l Hyper-V の統合サービス(Linux向け)のソースコードを公開!(2009.7.21)
l これを読めば Hyper-V の hypercall も解明できる？

で、どうやってダウンロードすればいいの？
l MS のサイトを漁りまわったけどソースコードを発見できず！！
l 公開を報じる国内記事は多々あれど、ソースそのもののリンクはどこにもない
l 駄目ぢゃん、っと思ってたら...

で、どうやってダウンロードすればいいの？
l Linux-Kernel ML に Greg-KH 氏が投稿していた
l パッチを 54 分割して...
l 何とか苦労して取り出しました
l 最近のカーネルソースには既に含まれている模様

ソースツリー: open-vm-tools の場合
l open-vm-tools
l 綺麗な階層構造、Makfile 完備
l さまざまなOSでのビルドを前提としている
l コード数、約24万行
- 「find –name ‘*.[ch]’ -print0 | xargs -0 wc –l 」の実行結果より

ソースツリー: open-vm-tools の場合
l open-vm-tools の階層構造
+-- autom4te.cache/
+-- checkvm/
+-- config/
+-- docs/
+-- hgfsclient/
+-- hgfsmounter/
+-- lib/
+-- libguestlib/
+-- libvmtools/
+-- m4/
+-- modules/
| +-- freebsd/
| +-- linux/
| +-- solaris/
+-- rpctool/
+-- scripts/
+-- services/
| +-- plugins/
|| +-- vmtoolsd/
+-- tests/
+-- toolbox/
+-- vmblock-fuse/
+-- vmware-user/
+-- vmware-user-suid-wrapper/
+-- xferlogs/
| +-- linux/
| | +-- pvscsi/
| | +-- shared/
| | +-- vmblock/
| | +-- vmci/
| | +-- vmhgfs/
| | +-- vmmemctl/
| | +-- vmsync/
| | +-- vmxnet/
| | +-- vsock/
独自のツリー構造
多くのOSに対応
共通化モジュール、ユーザランドツール、
ドライバなど綺麗に分離されている

ソースツリー: Hyper-V の場合
l linux integration component
l linux-kernel に対するパッチで、Linux にべったりの構造
- カーネルパッチだけ？ユーザランドに何もない？？
l driver/staging/hv 以下に集中配置
l 約2万行

ソースツリー: Hyper-V の場合
ファイル一覧
BlkVsc.c HvVpApi.h Vmbus.c
Channel.c Kconfig VmbusApi.h
Channel.h List.h VmbusChannelInterface.h
ChannelInterface.c Makefile VmbusPacketFormat.h
ChannelInterface.h Makefile.rej VmbusPrivate.h
ChannelMessages.h NetVsc.c blkvsc_drv.c
ChannelMgmt.c NetVsc.h hv.diff
ChannelMgmt.h NetVscApi.h logging.h
Connection.c RingBuffer.c netvsc_drv.c
Hv.c RingBuffer.h nvspprotocol.h
Hv.h RndisFilter.c osd.c
HvHalApi.h RndisFilter.h osd.h
HvHcApi.h Sources.c rndis.h
HvPtApi.h StorVsc.c storvsc_drv.c
HvStatus.h StorVscApi.h vmbus.h
HvSynicApi.h TODO vmbus_drv.c
HvTypes.h VersionInfo.h vstorage.h

Linux への侵食方法：VMware の場合
あくまで「物理デバイスに対するドライバ」の立場
l VMware-tools の有無に関わらず、仮想デバイスが存在する前提
l PCIバス上にデバイスがつながっているように見える
l PCIバスのデバイス検出手順に従い、ドライバがロードされていく
l VendorID: 0x15AD で、指定
の DeviceID をもつドライバが
選定される
l 選定されたドライバのprobe 関数を
実行して、本当に対応するデバイスか
を確認させる
l 失敗が帰ったら、次の候補となる
ドライバを探す
/* Our own PCI IDs
* VMware SVGA II (Unified VGA)
* VMware SVGA (PCI Accelerator)
* VMware vmxnet (Idealized NIC)
* VMware vmxscsi (Abortive idealized SCSI controller)
* VMware chipset (Subsystem ID for our motherboards)
* VMware e1000 (Subsystem ID)
* VMware vmxnet3 (Uniform Pass Through NIC)
*/
#define PCI_VENDOR_ID_VMWARE 0x15AD
#define PCI_DEVICE_ID_VMWARE_SVGA2 0x0405
#define PCI_DEVICE_ID_VMWARE_SVGA 0x0710
#define PCI_DEVICE_ID_VMWARE_NET 0x0720
#define PCI_DEVICE_ID_VMWARE_SCSI 0x0730
#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740
#define PCI_DEVICE_ID_VMWARE_CHIPSET 0x1976
#define PCI_DEVICE_ID_VMWARE_82545EM 0x0750 /* single port */
#define PCI_DEVICE_ID_VMWARE_82546EB 0x0760 /* dual port */
#define PCI_DEVICE_ID_VMWARE_EHCI 0x0770
#define PCI_DEVICE_ID_VMWARE_UHCI 0x0774
#define PCI_DEVICE_ID_VMWARE_XHCI 0x0778
#define PCI_DEVICE_ID_VMWARE_1394 0x0780
#define PCI_DEVICE_ID_VMWARE_BRIDGE 0x0790
#define PCI_DEVICE_ID_VMWARE_ROOTPORT 0x07A0
#define PCI_DEVICE_ID_VMWARE_VMXNET3 0x07B0
#define PCI_DEVICE_ID_VMWARE_VMXWIFI 0x07B8
#define PCI_DEVICE_ID_VMWARE_PVSCSI 0x07C0
#define PCI_DEVICE_ID_VMWARE_82574 0x07D0
lib/include/vm_device_version.h より

余談: vmxnet の Morphing
l ESX 2.x では、vlance と vmxnet は区別されてました
l vlance vendorID: 0x1022(AMD) deviceID: 0x2000
l vmxnet vendorID: 0x15AD(VMware) deviceID: 0x0720
l ESX 3.x 以降で、vlance -> vmxnet の入れ替えしました？

l ESX 3.x 以降の vlance は、vmxnet を「兼用」している
l たまたま、AMD-PCNET が 32byte しか IO空間を使ってなかった点を利用
l 64byte まで取れるIO空間の後ろ32byte に vmxnet の IO空間を追加
/*
* Since this is a vlance adapter we can only use it if
* its I/0 space is big enough for the adapter to be
* capable of morphing. This is the first requirement
* for this adapter to potentially be morphable. The
* layout of a morphable LANCE adapter is
*
* I/O space:
*
* |------------------|
* | LANCE IO PORTS |
* |------------------|
* | MORPH PORT |
* |------------------|
* | VMXNET IO PORTS |
* |------------------|
*
* VLance has 8 ports of size 4 bytes, the morph port is 4 bytes, and
* Vmxnet has 10 ports of size 4 bytes.
*
* We shift up the ioaddr with the size of the LANCE I/O space since
* we want to access the vmxnet ports. We also shift the ioaddr up by
* the MORPH_PORT_SIZE so other port access can be independent of
* whether we are Vmxnet or a morphed VLance. This means that when
* we want to access the MORPH port we need to subtract the size
* from ioaddr to get to it.
*/

l vmxnet ドライバの probe 関数(vmxnet_probe_device)の挙動
l PCI の Vendor ID を取得
- 0x15AD （VMware）なら、そのまま vmxnet デバイスと判断
• 旧 vmxnet との互換性の確保
- 0x1022 (AMD) の場合
• IO空間のサイズを取得し、64byte とサイズを比較
• それより小さかったら？「うちの子じゃない」で probe に失敗を返す
• 64byte 以上なら、「うちの子だから」と認定
• morph port に outw で値を書き込み、vmxnet として振舞わせる

static int
vmxnet_morph_device(unsigned int morphAddr) // IN
{
uint16 magic;
/* Read morph port to verify that we can morph the adapter. */
magic = inw(morphAddr);
if (magic != LANCE_CHIP && magic != VMXNET_CHIP) {
printk(KERN_ERR "Invalid magic, read: 0x%08X¥n", magic);
return -1;
}
/* Morph adapter. */
outw(VMXNET_CHIP, morphAddr);
/* Verify that we morphed correctly. */
magic = inw(morphAddr);
if (magic != VMXNET_CHIP) {
printk(KERN_ERR "Couldn't morph adapter. Invalid magic, read: 0x%08X¥n",
magic);
goto morph_back;
}
return 0;
morph_back:
/* Morph back to LANCE hw. */
outw(LANCE_CHIP, morphAddr);
return -1;
}

VMM
l あくまで正規のデバイスドライバとしてロードされる
l 比較的、物理デバイスに近いエミュレーションがなされている
l Backdoor を使ってデバイスエミュレーションをある程度「バイパス」する
Linux kernel
vmxnet_drv VGA LSILogic
NIC VGA SCSI
VendorID: xxxx
DeviceID : xxxx
VendorID: xxxx
DeviceID : xxxx
VendorID: xxxx
DeviceID : xxxx
PCI バス Backdoor
vmsync
vmUser
vmmemctl
VMkernel
vmtools 提供ドライバ
ネイティブドライバ

Backdoor : IO空間の in/out 命令
l VMware の Backdoor は、指定のIO空間への in /out 命令
l in / out : x86 のもつ IO 空間へのデータの読み書きの命令
l NICなどの一般的なデバイスは IO空間の一部を通じてデータをやり取りする
- グラフィックカードなどのより大きな空間を必要とするものは、メモリ空間
にマップされる
- PCI は IO空間 / メモリマップのどちらの方法もサポートする
l VMware ではこの in / out 命令を転用している
l 詳細: http://chitchat.at.infoseek.co.jp/vmware/backdoorj.html

static void
BalloonTimerHandler(void *clientData) // IN
{
Balloon *b = (Balloon *) clientData;;
uint32 target = 0;; // Silence compiler warning.
int status;;
/* update stats */
STATS_INC(b->stats.timer);;
/* reset, if specified */
if (b->resetFlag) {
BalloonReset(b);;
}
/* contact monitor via backdoor */
status = BalloonMonitorGetTarget(b, &target);;
/* decrement slowPageAllocationCycles counter */
if (b->slowPageAllocationCycles > 0) {
b->slowPageAllocationCycles--;;
}
if (status == BALLOON_SUCCESS) {
/* update target, adjust size */
b->nPagesTarget = target;;
(void) BalloonAdjustSize(b, target);;
}
}

static void
{
int status;;
/* update stats */
if (b->resetFlag) {
BalloonReset(b);;
}
}
}
}
static int
BalloonMonitorGetTarget(Balloon *b, // IN
uint32 *target) // OUT
{
Backdoor_proto bp;;
unsigned long limit;;
uint32 limit32;;
uint32 status;;
limit = OS_ReservedPageGetLimit();;
/* Ensure limit fits in 32-bits */
limit32 = (uint32)limit;;
if (limit32 != limit) {
return BALLOON_FAILURE;;
}
/* prepare backdoor args */
bp.in.cx.halfs.low = BALLOON_BDOOR_CMD_TARGET;;
bp.in.size = limit;;
/* invoke backdoor */
Backdoor_Balloon(&bp);;
/* parse return values */
status = bp.out.ax.word;;
*target = bp.out.bx.word;;

static void
{
int status;;
/* update stats */
if (b->resetFlag) {
BalloonReset(b);;
}
}
}
}
static int
BalloonMonitorGetTarget(Balloon *b, // IN
uint32 *target) // OUT
{
Backdoor_proto bp;;
unsigned long limit;;
uint32 limit32;;
uint32 status;;
limit = OS_ReservedPageGetLimit();;
/* Ensure limit fits in 32-bits */
limit32 = (uint32)limit;;
if (limit32 != limit) {
return BALLOON_FAILURE;;
}
/* prepare backdoor args */
bp.in.cx.halfs.low = BALLOON_BDOOR_CMD_TARGET;;
bp.in.size = limit;;
/* invoke backdoor */
Backdoor_Balloon(&bp);;
/* parse return values */
status = bp.out.ax.word;;
*target = bp.out.bx.word;;
static INLINE
void Backdoor_Balloon(Backdoor_proto *myBp) {
myBp->in.ax.word = BALLOON_BDOOR_MAGIC;;
myBp->in.dx.halfs.low = BALLOON_BDOOR_PORT;;
Backdoor_InOut(myBp);;
}

Backdoor_InOut(Backdoor_proto *myBp) // IN/OUT
{
uint32 dummy;
__asm__ __volatile__(
#ifdef __PIC__
"pushl %%ebx" "¥n¥t"
#endif
"pushl %%eax" "¥n¥t"
"movl 20(%%eax), %%edi" "¥n¥t"
"movl 16(%%eax), %%esi" "¥n¥t"
"movl 12(%%eax), %%edx" "¥n¥t"
"movl 8(%%eax), %%ecx" "¥n¥t"
"movl 4(%%eax), %%ebx" "¥n¥t"
"movl (%%eax), %%eax" "¥n¥t"
"inl %%dx, %%eax" "¥n¥t"
"xchgl %%eax, (%%esp)" "¥n¥t"
"movl %%edi, 20(%%eax)" "¥n¥t"
"movl %%esi, 16(%%eax)" "¥n¥t"
"movl %%edx, 12(%%eax)" "¥n¥t"
"movl %%ecx, 8(%%eax)" "¥n¥t"
"movl %%ebx, 4(%%eax)" "¥n¥t"
"popl (%%eax)" "¥n¥t"
#ifdef __PIC__
"popl %%ebx" "¥n¥t"
#endif
: "=a" (dummy)
: "0" (myBp)
/*
* vmware can modify the whole VM state without the compiler knowing
* it. So far it does not modify EFLAGS. --hpreg
*/
:
#ifndef __PIC__
"ebx",
#endif
"ecx", "edx", "esi", "edi", "memory"
);
}
この inl 命令の実行した瞬間に
VMkernel 側に処理が渡り、該当する
機能が実行され、結果が vCPU の
EAX 、ECX 、 EDX 、 ESI、EDI レジスタ
に書き込まれる

Hyper-V のドライバイメージ
l Hyper-V の場合は、デバイスではなく「バス」を追加している
l PCI バスの下に、なんかバスがある...
l なんかバスが「外」に伸びてるっぽい...
VMM
Linux kernel
レガシNIC VGA IDE
VendorID: xxxx
DeviceID : xxxx
VendorID: xxxx
DeviceID : xxxx
VendorID: xxxx
DeviceID : xxxx
PCI バス
ネイティブドライバ
21140 VGA IDE
VMBUS
Backdoor
vmbus_drv
netvsc_drv storage_drv
NIC SCSI
Hyper-V
ParentVM

Hyper-V のドライバイメージ
l Hyper-V の場合は、デバイスではなく「バス」を追加している
l PCI バスの下に、なんかバスがある...
l なんかバスが「外」に伸びてるっぽい...

Linux の侵食方法 : Hyper-V の場合
l とにかく vmbus_drv デバイスドライバをロードする
l VMBUS という何らかの「バス」があると Linux に誤認させる
l VMBUS も、PCI と同じようにバス上のノードの検出を行う
- VendorID と Device ID ではなく、ClassID という GUID で識別
- ノードごと、netvsc_drv, storagevsc_drv, blkvsc_drv がロードされる
• VSC : Virtualization Service Client の略
l 各 VSC はデバイスドライバだが、その下にはエミュレーションされたデバイス
はまったく存在しない!!

http://enterprise.watch.impress.co.jp/cda/parts/image_for_link/41502-13748-4-1.html
本当にこの通りでした...

もう少し詳しい階層構造
l 大きく4層に分かれる
l *_drv : Linux のデバイスドライバ(カーネルモジュール)としての体裁を整える
l Vsc, Vmbus : 各ドライバの実態となる実装
l Channel, Connection : VMBUS の通信機能の実装
l osd : メモリ確保など
OS機能の抽象化
l Hv : Hyper-V との
実際のインターフェイス
Linux kernel
osd
VMM
Vmbus
vmbus_drvstoragevsc_drvnetvsc_drv blcvsc_drv
Hv
Channel
Connection
Channel Mgmt
StorVscNetVsc BlcVsc
Linux Kernel とのインターフェイス
ドライバー中心部分
VMBUS 通信機能

Backdoor : そのメモリに触ると...
Hyper-V のバックドアは特定のメモリアドレス
l Hv はロードされると以下の振る舞いをする
l CPUID 命令を実行し、Hyper-V の上かを確認する
- CPUID(１）の ECXの31bit 目を確認
l 続けて CPUID 命令を実行し、ハイパーバイザのベンダー(!)や
バージョンを取得する
l メモリを1ページ確保する
- これは通常の valloc が使用され、実行時により異なるページが
割り当てられる
l wmsr でそのメモリの物理アドレスを vCPU に書き込む(!)
- MSR: Model Specific Register
• PentiumPro 以降のCPUにある、製品独自の設定を保存したり、
プロファイリング用のカウンタとなるレジスタ
• 詳細: http://mcn.oops.jp/wiki/index.php?CPU%2FCPUID%2FMSR
l 以降、Hypercall はこのメモリへのアクセスすると、Hypercall が発生する

Backdoor : Hv初期化部分、Hyper-V 上かを確認
Name:
HvQueryHypervisorPresence()
Description:
Query the cpuid for presense of windows hypervisor
--*/
static int
HvQueryHypervisorPresence (
void
)
{
unsigned int eax;
unsigned int ebx;
unsigned int ecx;
unsigned int edx;
unsigned int op;
eax = 0;
ebx = 0;
ecx = 0;
edx = 0;
op = HvCpuIdFunctionVersionAndFeatures;
do_cpuid(op, &eax, &ebx, &ecx, &edx);
return (ecx & HV_PRESENT_BIT);
}

Name:
Description:
--*/
static int
void
)
{
unsigned int eax;
unsigned int ebx;
unsigned int ecx;
unsigned int edx;
unsigned int op;
eax = 0;
ebx = 0;
ecx = 0;
edx = 0;
}
typedef enum _HV_CPUID_FUNCTION
{
HvCpuIdFunctionVersionAndFeatures = 0x00000001,
HvCpuIdFunctionHvVendorAndMaxFunction = 0x40000000,
HvCpuIdFunctionHvInterface = 0x40000001,
//
// The remaining functions depend on the value of HvCpuIdFunctionInterface
//
HvCpuIdFunctionMsHvVersion = 0x40000002,
HvCpuIdFunctionMsHvFeatures = 0x40000003,
HvCpuIdFunctionMsHvEnlightenmentInformation = 0x40000004,
HvCpuIdFunctionMsHvImplementationLimits = 0x40000005
} HV_CPUID_FUNCTION, *PHV_CPUID_FUNCTION;

Name:
Description:
--*/
static int
void
)
{
unsigned int eax;
unsigned int ebx;
unsigned int ecx;
unsigned int edx;
unsigned int op;
eax = 0;
ebx = 0;
ecx = 0;
edx = 0;
}
static inline void do_cpuid(unsigned int op, unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm__ __volatile__("cpuid" : "=a" (*eax), "=b" (*ebx), "=c" (*ecx), "=d" (*edx) : "0" (op),
"c" (ecx));
}

Name:
Description:
--*/
static int
void
)
{
unsigned int eax;
unsigned int ebx;
unsigned int ecx;
unsigned int edx;
unsigned int op;
eax = 0;
ebx = 0;
ecx = 0;
edx = 0;
}
//
// #defines
//
#define HV_PRESENT_BIT 0x80000000

Hyper-V 上の仮想マシンでの
CPUID 。確かに ECX の31bit目が
立っている
ESX上の仮想マシン
31bit 目は立っていない
0x8C082201
0x80000000
0x80000000
OR
0x00080201
0x80000000
0x00000000
OR

Backdoor : Hv初期化部分、アクセス用のアドレスを設定
if (gHvContext.GuestId == HV_LINUX_GUEST_ID)
{
// Allocate the hypercall page memory
//virtAddr = PageAlloc(1);;
virtAddr = VirtualAllocExec(PAGE_SIZE);;
if (!virtAddr)
{
DPRINT_ERR(VMBUS, "unable to allocate hypercall page!!");;
goto Cleanup;;
}
hypercallMsr.Enable = 1;;
//hypercallMsr.GuestPhysicalAddress = Logical2PhysicalAddr(virtAddr) >> PAGE_SHIFT;;
hypercallMsr.GuestPhysicalAddress = Virtual2Physical(virtAddr) >> PAGE_SHIFT;;
WriteMsr(HV_X64_MSR_HYPERCALL, hypercallMsr.AsUINT64);;
// Confirm that hypercall page did get setup.
hypercallMsr.AsUINT64 = 0;;
hypercallMsr.AsUINT64 = ReadMsr(HV_X64_MSR_HYPERCALL);;
if (!hypercallMsr.Enable)
{
DPRINT_ERR(VMBUS, "unable to set hypercall page!!");;
goto Cleanup;;
}
gHvContext.HypercallPage = virtAddr;;
osd.c にて定義。単に __valloc を
呼び出しているのみ。
単なるメモリ確保のため、どのアドレスが
変えるかは実行依存の模様
仮想アドレスを物理アドレスに書き換えた後、
CPU の MSR レジスタにアドレスを書き込む

Backdoor : Hypercalｌの実際
static u64
HvDoHypercall (
u64 Control,
void* Input,
void* Output
)
{
#ifdef CONFIG_X86_64
u64 hvStatus=0;
u64 inputAddress = (Input)? GetPhysicalAddress(Input) : 0;
u64 outputAddress = (Output)? GetPhysicalAddress(Output) : 0;
volatile void* hypercallPage = gHvContext.HypercallPage;
DPRINT_DBG(VMBUS, "Hypercall <control %llx input phys %llx virt %p output phys %llx virt %p hypercall %p>",
Control,
inputAddress,
Input,
outputAddress,
Output,
hypercallPage);
__asm__ __volatile__ ("mov %0, %%r8" : : "r" (outputAddress): "r8");
__asm__ __volatile__ ("call *%3" : "=a"(hvStatus): "c" (Control), "d" (inputAddress), "m" (hypercallPage));
DPRINT_DBG(VMBUS, "Hypercall <return %llx>", hvStatus);
return hvStatus;
RCXに命令コードを、RDX に入力データのアドレスを
突っ込んだ後、hypercallPage に call でジャンプし、
Hypercall を行っている (コールゲート？)

Backdoor : そのメモリに触ると...
l 割り込み、どうするのん？
l VMware の場合、各デバイスは PCI 上のデバイスのため、PCIバスを通じて
個々のデバイスが (ゲスト)OSへ割り込みをかけることができた
- = VMM 側からゲストOSにデータを投げることができた
l Hyper-V の場合は？
l Linux Intergrated Module では、 IRQ 5 を VMBUS の割り込みとして使用

余談: なぜ、Hyper-V の起動ディスクは IDE only なのか
l VMBUS がないと統合モジュールが動かないため
l OS ロード前は、VMBUS などというバスを認識できない
l そもそも仮想マシンの上の BIOS レベルで VMBUS ドライバを実装する必要
l OS ロード後なら、追加的に VMBUS をロードできる

まとめ
l 同じハイパーバイザ型の仮想化ソフトウェアでも、Hypercall の
方法は各社各様
l 意外ときっちり実装している ESX の VMM
l vmxnet ドライバも割と普通に IO 処理を行っている
l 物理とは大きく異なる Hyper-V の VMM
l エミュレートされたデバイスとは別に、本当に架空のデバイスを生成
l VMBUS という架空のバスを通じて架空のデバイスを接続
l 原理的に、morphing はできない。
- エミュレートデバイスと架空のデバイスは永久に混在する見込み

Backdoor!! vmware-tools と統合サービスに見るハイパーバイザの呼び出し方

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Backdoor!! vmware-tools と統合サービスに見るハイパーバイザの呼び出し方

Similar to Backdoor!! vmware-tools と統合サービスに見るハイパーバイザの呼び出し方 (20)

Recently uploaded

Recently uploaded (8)