Intel's statement is an outright, purposeful deception. They brought up the spectre of data modification and completely avoided mentioning the actual bug, which is the ability to read the contents of kernel memory, when not a single person was talking about data modification and everyone was talking about the ability to read kernel memory. Being able to read kernel memory completely destroys the security of the machine, period. You don't NEED to be able to modify memory when you can steal the encryption keys!
Intel then went on to try to include all other cpu vendors in their little party, to make it seem like it was normal or at least not something Intel-specific. Except this bug *IS* Intel-specific. AMD doesn't suffer from it. ARM doesn't suffer as badly. Sure, there are generally some issues due to speculative timing attacks. But this bug on Intel is the thousand-pound gorilla and they are playing light with it in their statements.
And also in statements, Intel is trying to pass-off the 'fix' that all of us OS programmers have to do, as being something minor. It isn't minor. We have to completely destroy user->kernel transition efficiency by changing out the MMU page tables (%CR3 reload) for every user->kernel and kernel->user transition. THAT SUCKS ROCKS! 150ns system call overhead increases to over 400ns. that isn't minor. That's a show-stopper.
It may be that some classes of problems won't care so much, because they don't make a lot of system calls or take a lot of interrupts, but I guarantee you that there are a LOT of classes of problems that do care, particularly on the server side and in the cloud. I sure as hell care. Intel is wasting god knows how many millions of man hours of people's time dealing with this junk.
All because Intel can't get its house in order. First the management engine, then the hyper-threading bug, and now this junk. I'm sick and tired of it.
-Matt