Control-flow processor exceptions (single-stepping on branches) on control-flow branch instructions (jmp/call/ret)

"single-stepping on branches" is processor hardware feature of x86/Intel architecture. When it is enabled, the processor generates a single-step debug exception only after instructions that cause a branch. This mechanism
allows a debugger to single-step on control transfers caused by branches. What does this imply to defense against control-flow hijacking attacks (e.g. ROP or JOP) ? 

How to defend against Stack Pivoting attacks on existing 32-bit x86 processor architecture?

Stack Pivoting is a common technique widely used by vulnerability exploits to bypass hardware protections like NX/SMEP, or to chain ROP (Return-Oriented Programing, the Wikipedia link) gadgets. However, there is NO hardware protection solution to defend against it (at least for now:-). This blog will describe a software solution to detect Stack Pivoting at run time, and I will also point out some limitations due to current processor architecture implementations.  <Please let me know if this is NOT a new idea, or NOT doable.>

Improve Performance for Separating Kernel and User Address Space with Process-Context Identifiers (PCIDs)

This post is not talking about any new idea, just about what I'm thinking..

Anybody knows How to Legitimately Register a PMI (PMU Performance Monitor Interrupt) Callback Handler on Windows OS?

According to IA32/Intel Software Development Manual, when some PMU (Performance Monitor Unit) counter overflows occur, or LBR (Last Branch Record)/BTS (Branch Trace Store) is near full, the processor will deliver a PMI (Performance Monitor Interrupt). In Linux Kernel implementation, the PMU (perf tool) is using NMI to deliver such a PMI interrupt, and we can directly change the kernel source to add our own PMI handler for a particular event. 

But in Windows OS, how to register a PMI handler callback in a driver without hooking the kernel IDT table? Does anybody know about it? 

Implement software-based SMEP with Non-Execute (NX) bit in page tables to secure kernel/user virtual memory address space.

In my previous post, I talked about how to implement a software-based SMEP (Supervisor Mode Execution Protection) with virtualization/hypervisor for fun. In this post, I'm going to detail yet another solution to implement software-based SMEP without virtualization technology. 

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). 

Kernel Information Leak with Unprivileged Instructions (SIDT, SGDT) on x86 - WHY ?

In computer security, information leaking is one of threats to software security. For example, the memory address of kernel critical resource should not be visible to user mode. Address space layout randomization (ASLR) is just one of techniques to prevent an attacker from reliably getting a particular exploited function in memory. 

However, I'm just very curious about why x86 processor leaks kernel data structures by some unprivileged instructions. Is this a bad CPU design?

Exploit NULL pointer dereference bug (ARM and x86)

A NULL pointer dereference occurs when a pointer with the value of 0 (NULL) is assumed to be a valid memory location, and that pointer is then accessed. A write from, or read to, the memory address 0x0 (+ small-offset) will generally reference invalid or unused memory, which typically leads to the majority of published denial-of-service (DoS) attacks both locally and remotely.

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.