Common security design issues in privileged hypervisor or in any privileged emulators

Recently I've reviewed nearly 100 Xen Security Advisories (http://xenbits.xen.org/xsa/), except some bad security coding practices for any ordinary software, I found there are some specific security issues that we need to take into considerations when designing prvilieged hypervisors or privileged emulators.

"What, How, and Why" on Interrupt Window (or NMI Window) Exiting in Virtualization Technology

More recently, one of my colleagues asked me why there is a feature called "Interrupt Window exiting" in virtualization technology, and how it can be used by VMM? This blog is going to briefly describe its "what, how and why" .

Defending Against ret2dir Attacks (partially) with Virtualization Technology?

I was so excited when recently reading the paper (ret2dir: Rethinking Kernel Isolation) from Vasileios P. Kemerlis. This post is basically going to introduce the idea of ret2dir attack, and how to prevent such an attack with hardware virtualization technology, actually partially. 

Using LBR (Last Branch Record) Feature to Detect IDT-Shadowing-Based Malicious IDT Hooking

Thanks to Yushi who shared a presentation (ELI: Bare-Metal Performance for I/O Virtualization) with me. In that hypervisor (ELI), it innovates an idea of gust IDT shadow (or IDT virtualization) design for some specific usage models. I'm going to talk a little bit about this idea.

Monitor Trap Flag (MTF) Usage in EPT-based Guest Physical Memory Monitoring

Monitor Trap Flag (MTF) is a flag specifically designed for single-stepping in x86/Intel hardware virtualization VT-x technology. When MTF is set, the guest will trigger a VM Exit after executing each instruction (need to consider NMI or other interrupt delivery boundary). This paper presents an idea to use MTF for memory write allowing when monitoring modification to guest virtual-to-physical mapping (page table entries) tables. 

Debugging Bug Check (BSOD) 0x101 CLOCK_WATCHDOG_TIMEOUT in a Hypervisor/VMM Environment

I'm planning to write a post for debugging  Bug Check 0x101 issue (CLOCK_WATCHDOG_TIMEOUT) in Windows system. but I happened to find this blog Debugging a CLOCK_WATCHDOG_TIMEOUT Bugcheck from MSFT debugger team which explaned it in greater details. However, the issue we met is slightly different from what MSFT team was debugging. We are working in virtualization/hypervisor environment, and Windows (7+) is running as a primary Guest OS.  

Why smaller code size with XEN on ARM?

This white paper (Xen ARM with Virtualization Extensions whitepaper) indicates that "Xen on ARM is 1/6 of the code size of x86_64 Xen, while still providing a similar level of features". what does this mean? Does this mean that Xen/ARM is better than Xen/x86? We cannot simply just make this conclusion, but anyway smaller code size means smaller TCB, which can reduce security risks (e.g. security vulnerabilities). 

ARM TrustZone (Security Extension) and Virtualization Extension vs x86 Virtualization Technology

A typical virtualization system on both x86 and ARM includes three major parts:

• CPU virtualization
• Memory virtualization, and 
• I/O virtualization (device, interrupt virtualization). 

Monitor/Trap Software Interrupt INT 80h (System Call) with x86/Intel Virtualization Technology

In an unix-like system, before syscall/sysret and/or sysenter/sysexit instructions were introduced by x86/Intel processors, software interrupt "INT 80h" was used as system call interface. Unlike my previous post, this one is going to talk about how to monitor this old type system call.

Yet Another Solution to Monitor/Trap SYSCALL with Virtualization Technology (x86)

This article describes an idea to monitor SYSCALL with x86 Hardware Virtualization Technology. It doesn't require visible guest code/data modification, so that in some cases, even Kernel Patch Protection (e.g. Windows x64 PatchGuard) cannot detect it. Here the SYSCALL could also be SYSENTER or INT 80h for system calls.

Thoughts on VMXON and VMCS regions in VT-x (from security's point of view)

Previously when I was working on a Hypervisor based on Intel VT-x. I always did exactly as what I'm told to do in the VT-x specification when programing VMM software. 
But now I'm going to revisit this again starting by asking these questions: What if I won't do it as what we're told to do? Is Intel VT-x exploitable? Can we find vulnerabilities in hardware VT-x implementation? Is it possible to do "reverse-engineering" to get internals on VT-x CPU implementation? Can we take advantage of VT-x to attack other privileged resource? Can we bypass EPT layer?  However, those are just some open questions, I don't have answers either, but it has a lot of fun when you look into it.

Monitoring Windows OS scheduling events in a noninvasive way with Hardware Virtualization technology (Anti-Rootkit)

A rootkit is a stealthy type of software, typically malicious, designed to hide the existence of itself or certain processes/programs from normal methods of detection and enable continued privileged access to a computer. However, even though the malicious process/program can be invisible to users, internally it must have to get time slices for running, otherwise if it has no chance to get scheduled by CPU, such an existence is meaningless for malware author. 

This article provides a solution to detect the malware and inspect its behaviors by monitoring each OS thread scheduling event.

Debug Registers on Intel x86 Processor Architecture (with or without VT-x)

Intel processor architectures provide debug facilities for use in debugging code and monitoring system behaviors. Such a debug support is accessed using debug registers (DR0 through DR7), and handled by a dedicated exception routine. 

Debug registers (Dr0~DR3) hold the addresses of memory and I/O locations called breakpoints. Breakpoints are user selected locations in a program, a data-storage area in memory, or specific I/O ports. They are set where a programmer or system designer wishes to halt execution of a program and examine the state of the processor by invoking debugger software. A debug exception (#DB, vector = 1) is generated when a memory or I/O access is made to a breakpoint address.