Thoughts on Hardware Virtualization Exception (#VE)

Recently in the latest Intel SDM, you can find that there is a new exception type, Virtualization Exception, in Chapter 6 (Interrupt and Exception Handling) of  VOL2.

What is it? How to use it? ...

Introduction to Processor Hardware Security Features in x86 & ARM Architectures

x86 and ARM processors both provide many hardware enforced security features, e.g. NX (No-eXecute) for executable space protection, to help system software engineers to build a secure computing environment. 

This article summaries those security features for both x86/Intel and ARM architectures, and explains how are they used by Operating System.

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.

How to get to know the memory address at which my code/data is actually loaded at boot initialization stage?

In embedded software development, sometimes when you're writing a PIC (position independent code) boot code, you might need to know at which memory address my bootstrap code/data is loaded by a loader at runtime. This article discusses the solutions to this question with assembly language implementation (x86). 

Good practices for programming with hardcode

What a contradiction!

Programming with many hardcodes is not a good practice because it is hard to understand and also has maintainability issue, for example, when a condition is changed for some reason, the previous well-tuned hardcode value might not be working any more.

However, when there are some conditions under which we must have to write hardcodes when programming, then what're good practices? The rest of this article is focusing on this. 

Approach to retrieving the physical memory map on different system (SFI, LEGACY,UEFI)

According to Wikipedia, in computer science a memory map is a structure of data (which usually resides in memory itself) that indicates how the memory space is laid out. In the boot process, a memory map is passed on from the firmware in order to instruct an operating system kernel about memory layout. It contains the information regarding the size of total memory, the range of specific memory space and any reserved regions, it may also provide other details specific to the architecture and platform.

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.

Multiboot Specification and limitations (Bootloader -> OS)

Typically in a computer system, the boot sequence is like this: firmware -> bootloader -> Operating System.  The problem is that nowadays we have the largest variety of operating systems, boot loaders, and firmwares (UEFI/Legacy), and even some of them are proprietary software that are not public. So, the interaction might be a problem if the interface is not well-defined. 

TESTING

This is a test, just a test!