Fun! If you're interested in Linux kernel security, you should read the whole post, rather than jumping to conclusions about what it means right now.

SMEP is a processor feature that will disallow execution of instructions from pages marked as belonging to userland when the CPU is executing in CPL0 (kernel mode). SMEP makes life annoying for memory corruption exploit authors because it prevents them from using the userland memory they already control to hold shellcode.

BPF is part of the network monitoring code in the Linux (and BSD) kernel; it's what tcpdump expressions compile down to. BPF is a trivial two-register VM that implements matching on packet fields to select which packets will be shuttled (at great expense) into userland for pcap programs to look at. Modern Linux kernels have BPF implementations that compile down to native code.

JIT-spraying is a technique Dion Blazakis invented (and my friend Chris Rohlf, formerly on the Matasano team, spent several years working with). It notices that systems implementing JITs often give attackers control over executable code, even though the system is being careful not to allow data to be treated as instructions. JIT-spray attacks give a victim JIT code that when compiled will help abet an exploit; it's "sprayed" because the attacker does this repeatedly in order to fill the victim's memory with malicious code to make it easier to jump to during an exploit.

The coolest trick in this post is how they've accomplished the "spraying"; because there's a limit on open files and only one BPF filter can be attached to one, they need a way around resource limits. So they use explicit file descriptor passing, which is an obscure Unix feature that allows unrelated processes to send and receive open files over Unix domain sockets using sendmsg(2). By sending sockets with malicious BPF code attached, the technique forces the kernel to keep those BPF filters resident, while allowing the exploit code to close its own copy, freeing up space for a new socket.

The point of this post isn't "OMG Linux is doomed"; it's that it's difficult to blunt memory corruption attacks with simple countermeasures. 15 years ago, researchers thought they'd killed memory corruption code execution off for good with stack cookies; the years that followed have been a story of new countermeasures introduced, hailed as a single bullet, bypassed by clever attacks, and then fit into a patchwork of defenses that have made exploits progressively harder, but not close to impossible, to build.

But at least hardware vendors (Intel in this case) are giving software (Linux) more tools to protect themselves. Unfortunately, just like with the great hardware security provided by IBM for the PS3, software bugs mitigate many of these hardware protections!