@Zerosquare said in WTF Bites:
Huh?
Intel added the bound
instruction for checking that a number was within a lower and an upper bound, and throwing a "bound range exceeded" exception if it wasn't. This is useful for arrays (either by index or by pointer), jump tables, and other such things. It's also useful for most of the cases where overflow would be a problem: guarding against blowing out the end of a buffer by checking whether it's being accessed past the end, and getting whether it's being accessed before the start for free.
There's also the into
instruction that threw an "overflow" exception if the overflow flag is set. Less flexible than the bound
instruction, but perfect for detecting someone's doing shenanigans.
Both of these execute very quickly in the common case (bounds are correct, no overflow), don't involve the branch predictor, and don't add any register pressure. They do require some care and handling since they call into the process' interrupt vector table, but all of that is manageable. They're not recommended for loop controls because it's relatively expensive handing the thrown exception, not least because of the IVT interaction. In kernel and drive code, however, even that expense is cheap, and well worth it.
And then VIA fucked that up with their C3 processor.
VIA added a special backdoor where, by executing an undefined (by Intel and AMD) instruction, you could smuggle code to a secondary processor that runs at systems management mode level and perform arbitrary actions behind the OS' back. The code you wanted to smuggle was in the x86 instruction stream as operands to bound
instructions. I understand NS had a similar backdoor that taints into
.
For this and other reasons (Microsoft's and Borland's compilers never used them), AMD de-defined those instructions when designing AMD64, Intel followed suit, and even in 32-bit code any usage of them is considered virus-like behavior regardless of legitimacy.