4 ms·
Hardware undefined behavior. The hardware can do anything. That includes trapping on an illegal instruction or something, but there is no guarantee that some C
by fluffything 6y ago
Hardware undefined behavior. The hardware can do anything.
That includes trapping on an illegal instruction or something, but there is no guarantee that some CPU that was designed and built before SSE4 existed will do anything meaningful when fed with machine code that it was never intended to see.
You are basically hopping for the instruction decoder to be "really good", and not "really fast". Eg. suppose that there is only one instruction in SSE3 which has the 7th bit set. A fast instruction decoder tests that bit, and if its true, it knows exactly what instruction that is. Years later, SSE4 is designed and implemented, and it adds another instruction that also has that bit set. You are required to check whether the CPU supports SSE4, and the SSE3-only CPU will tell you that it does not. If you then go ahead and feed it a SSE4 instruction, the CPU can do really anything, including executing some other completely different instruction.
- orra 6y agoInteresting, but how is that not a security flaw? Sounds like user space applications can cause CPU level undefined behaviour!?
- fluffything 6y agoWhen running a user space program, instead of executing the instruction in the assembly, the CPU will at best raise an exception, and at worse attempt to execute some other instruction. If the process doesn't have privileges to execute that other instruction, then the CPU will just raise an exception (unless if it has a big hardware bug). I don't see how this could be a security flaw.