Ahh. According to
this Reddit thread, it's also affecting the combination of nVidia binary drivers and newer-generation Intel CPUs.
Basically, IBT (short for Indirect Branch Tracking) is a security feature where either the compiler or, in fancier cases, the program needs to mark the intended behaviours and then the CPU hardware itself will faul into the kernel if things don't unfold that way.
First was protected mode, where programs in OSes with memory protection (eg. Windows NT, parts of Windows 9x not needed for backwards compatibility, Linux, Mac OS X, etc.) would slam into a wall and die if they tried to read or write memory they hadn't asked the kernel to grant them, thus preventing them from corrupting or crashing other things. (Technically, that works by having the kernel only install virtual-to-physical mappings for memory addresses granted to the program, so the CPU will jump into the kernel with a "couldn't look that up" error.)
Then, AMD's NX-bit (No eXecute) which Intel called ED-bit (Execute Disable) and Microsoft referred to by the broader term "Hardware DEP", which allowed the OS to adopt a policy that, except for old programs that need backwards compatibility, memory is either marked as writable or as executable but not both and programs like JIT compilers needed to be updated to stop opting out of it and, instead, all a special API to say "OK, I'm done generating this code, now lock it and allow it to be executed". (Again, the CPU then jumps into a kernel handler if it runs into a disallowed operation.)
This is also why trying to dereference NULL pointers crashes programs. As a protection, modern kernels leave page of memory (i.e. 1K to 4K, depending on platform) containing the 0 address (or whichever NULL is as a literal value) unmapped.
IBT is part of a set of new protections Intel cooked up named CET (Control-flow Enforcement Technology). I can't remember which Ryzen generation added them.
I'm not particularly familiar with IBT specifically, but I think you'll get the gist of what the CET suite of features do if I explain Shadow Stack (another piece of CET) instead.
Basically, the idea behind Shadow Stack is that, whenever the program hits a CALL instruction to call a function, the CPU not only updates the visible call stack, but also a hidden backup copy stored in "a location who cannot be named" (i.e. stored in physical memory with no virtual address mapping to it). When the program hits a RET instruction to return from the function, the CPU verifies that the visible and hidden copies match and jumps into the kernel handler if they don't. (Basically, think of it as solving an exploit where you could no longer bulldoze a road in front of you wherever you want, but you could go anywhere as long as you forged the map of where you've been and let the system think it was just retracing its steps. This, known as ROP or Return-Oriented Programming, has become popular since things like NX-bit started to get proper uptake in things like the JIT engines in JavaScript runtimes which need to be able to write to memory and then execute it at certain points in their operation but not others.)
IBT, Shadow Stack, etc. all handle different ways that an exploit can trick a program off the rails into executing code the attacker wants.
As for what IBT is. "Branch" is the CPU term for instructions like "jump to memory address A if the values we just compared were not equal" (JNE) and an indirect branch is one where, instead of "Jump to memory address A", it's "Read an address B from the memory at address A and then jump to that address B".
I think you can see why something that emulates or virtualizes another OS or platform would require the most manual programmer involvement in these sorts of things.
Because indirect branches, by their very nature, are for things that cannot be guaranteed to be known at compile time, IBT works by creating a new CPU instruction that just means "it's valid to land here" and changing the branching operations so, if they jump and the requested target isn't a valid landing pad, they'll fault into the kernel instead where, as with all of these other protections, the kernel can then choose to kill the program (the default) or hand off to the debugger so you can inspect it.
https://blog.danielwellman.com/2008/10/real-life-tron-on-an-apple-iigs.html has a very entertaining exploration of what happens when this sort of thing goes awry on a platform without memory protection.
Facebook
Twitter