Secure OOB-VNC Using Shadow Devices for VM Migration Support
Explore how to achieve secure out-of-band VNC using shadow devices for virtual machine migration support. Learn about the challenges of information leakage in OOB-VNC, VSBypass technique to prevent it, and the issue of migrating secure OOB-VNC setups. Discover SDmigrate for enabling continued secure OOB-VNC after VM migration.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
VM Migration Support for Secure Out-of-band VNC with Shadow Devices Tomoya Unoki and Kenichi Kourai Kyushu Institute of Technology, Japan
2 Out-of-band VNC (OOB-VNC) Cloud users manage virtual machines (VMs) remotely Often run VNC servers inside VMs This method relies heavily on the target systems in VMs Clouds provide the other method called out-of-band VNC Users access the systems in VMs indirectly via the virtual devices They can manage their systems at boot time or on system failures virtualized system VNC client VM VNC server VNC server virtual devices user cloud
3 Information Leakage in OOB-VNC Virtual devices are not sufficiently protected Cloud operators can easily access virtual devices They can obtain the inputs and outputs of OOB-VNC Not all the cloud operators are always trusted 28% of cybercrimes are insider attacks [PwC 14] 35% of system admins have stolen sensitive information [Cyberark 09] virtualized system cloud operators VNC client password, screen, etc. VM virtual devices user
4 VSBypass [Futagami+, ACSAC'18] Achieve secure OOB-VNC by providing shadow devices Run shadow devices outside the virtualized system Run the virtualized system in an outer VM using nested virtualization Access shadow devices instead of virtual devices Prevent information leakage to cloud operators Cloud operators are confined in the virtualized system virtualized system (cloud VM) VNC client input/output shadow devices virtual devices user VM remote host
5 Migration Issue in Secure OOB-VNC Secure OOB-VNC cannot be continued after VM migration The internal states of shadow devices are not transferred The migration utility handles only states inside the virtualized system The external state of a shadow video card cannot be identified The video memory (VRAM) in a VM's memory is transferred, but... virtualized system (cloud VM) virtualized system (cloud VM) state state transfer shadow devices user VM migration utility migration utility user VM shadow devices state source host destination host
6 SDmigrate Enable continuing secure OOB-VNC after VM migration The migration utility can handle the states of shadow devices Both the internal and external states Modifications to the migration utility are not necessary Information leakage from the transferred states is prevented virtualized system (cloud VM) virtualized system (cloud VM) state state state state transfer shadow devices user VM migration utility migration utility user VM shadow devices restore save source host destination host
7 Fake Devices A naive design is that the migration utility directly saves and restores the states of shadow devices Not acceptable because the migration utility needs to be modified Introduce fake devices inside the virtualized system Use to transparently save and restore the states of shadow devices Created as virtual devices of a user VM virtualized system (cloud VM) user VM shadow devices fake devices migration utility
8 Save/Restore with Fake Devices The migration utility saves the state of a fake device The fake device sends a request to the corresponding shadow device It receives the state of the shadow device The migration utility restores the state of a fake device The fake device sends the state to the corresponding shadow device virtualized system (cloud VM) virtualized system (cloud VM) state state transfer shadow devices fake devices migration utility migration utility fake devices shadow devices save restore source host destination host
9 Communication between Fake/Shadow Devices Not easy to securely and efficiently communicate between fake and shadow devices Inter-process communication cannot be used The virtual network affects security and performance Shadow devices need to permit access to cloud operators as well Impose communication overhead cloud operators virtualized system (cloud VM) shadow devices fake devices virtual network
10 Secure Communication with Shared Memory A fake device directly invokes the cloud hypervisor Completely bypass the virtualized system The cloud hypervisor invokes the corresponding shadow device The shadow device shares the memory of the fake device Can avoid active attacks from cloud operators Encrypt its state before writing it to the shared memory virtualized system (cloud VM) shadow devices shared memory fake devices cloud hypervisor
11 Restoring External States (VRAM) The address of VRAM is identified by trapping memory- mapped I/O at the boot time of a VM Such I/O is not executed by the VM at migration time Transfer the address of VRAM to the destination host Translate the address in a user VM into that in the cloud VM Need the extended page tables (EPT) used for the user VM virtualized system (cloud VM) user VM access shadow video card VRAM EPT address translation
12 Identifying EPT Trap EPT configuration done by the virtualized system At both boot time and resume time VSBypass relied on the method applicable only to boot time Need to slightly modify the virtualized system for KVM EPT entries are not created until a VM accesses VRAM in KVM Modified to pre-allocate EPT entries virtualized system (cloud VM) user VM shadow video card VRAM EPT trap cloud hypervisor
13 Experiments We have implemented SDmigrate in Xen 4.8 Support secure out-of-band VNC and VM migration Support KVM and Xen as a virtualized system in the cloud VM We conducted several experiments using SDmigrate Compared with traditional and nested virtualization VM for the virtualized system Gigabit Ethernet target VM vCPU: 2 Memory: 3 GB vCPU: 2 Memory: 256 MB to 2 GB remote host source host destination host CPU: Xeon E3-1226 v3 Memory: 8 GB
14 Migration Time in SDmigrate We measured the time taken for VM migration Slightly longer than nested virtualization for a VM with 512 MB+ 0.1-0.6% (KVM) and 2.2-3.5% (Xen) Comparable to even traditional virtualization in KVM 1.6-21% (KVM) but 2.6-4.5 times (Xen) 20 120 KVM Xen migration time (sec) migration time (sec) 100 traditional nested SDmigrate traditional nested SDmigrate 15 80 10 60 40 5 20 0 0 256 MB 512 MB 1 GB 2 GB 256 MB 512 MB 1 GB 2 GB
15 Downtime in SDmigrate We measured the time for which a VM temporarily stops Usually longer than nested virtualization due to handling extra states 1-66 ms (KVM) and 61-175 ms (Xen) Comparable to traditional virtualization in Xen The reason is unclear 1000 500 KVM Xen traditional nested SDmigrate 400 800 downtime (ms) downtime (ms) 300 600 200 400 100 200 0 0 256 MB 512 MB 1 GB 2 GB 256 MB 512 MB 1 GB 2 GB
16 Conclusion SDmigrate enables secure OOB-VNC after VM migration Transparently and securely save/restore the states of shadow devices Via fake devices inside the virtualized system Handle both the internal and external states of shadow devices The degradation of migration performance was negligible Future work Support various virtualized systems E.g., Hyper-V, which does not use QEMU as a device emulator
