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

Unikernels: Library Operating Systems for the Cloud (OSv)

Unlike a general-purpose, commercial operating system (like Windows, Ubuntu), OSv (http://osv.io/ from cloudius-systems) is a single-purpose operating system. It is also kind of library operating system designed for the cloud that running on top of different hypervisors, e.g. XEN, KVM, VMware. So what does OSv like look? 

Security OS Kernel Design: an idea to prevent malicious software overwriting the critical system kernel data structures

Recently, when reading this paper "HyperSafe - A Lightweight Approach to Provide Lifetime Hypervisor Control-Flow Integrity", an idea just comes out from my mind: using write protection (CR0.WP) and read-only (RO) page attribute to prevent the critical kernel data structures being overwritten by malicious software through buffer (stack, heap) overflow in an exploitable kernel module.

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.