I don't know much about CPUs, so what prevents a fix via microcode update?
The bug seems to be revolving around speculative execution. It seems like that is a silicon thing, not a microcode thing.
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
131–140 of 567 posts
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#132I wonder what implications this will have on those who run Intel in their gaming rigs. I'm due to refresh, and _was_ gonna invest in Intel as my CPU. But this seems pretty damning for that.
I assume the system calls to interact with the GPU, or to do any sort of I/O, are going to incur the performance overhead. So rendering frames, reading/writing from the network, and loading assets from the disk could all cause issues.
And this is just for gaming. Anyone using a cloud provider that's running on Intel needs to worry about similar things.
What a nightmare...
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#133I wonder what implications this will have on those who run Intel in their gaming rigs. I'm due to refresh, and _was_ gonna invest in Intel as my CPU. But this seems pretty damning for that. I assume the system calls to interact with the GPU, or to do any sort of I/O, are going to incur the performance overhead. So rendering frames, reading/writing from the network, and loading assets from the disk could all cause iss…
Apparently zero effect: https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-...
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#134Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#135Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege esca…
The privilege escalation is being fixed in software. The problem is that mitigation involves patching the kernel and that patch results in around 30% slowdown for some applications like databases or anything that does a lot of IO (disk and network). That's the big deal. Imagine you are running at close to full capacity after security fix reboot your service might tip over. It could mean a direct impact to cost and so…
I would love to see some SQL Server benchmarks on this patch
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#136Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege esca…
It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it.
Indeed, this reminds me of cache-timing attacks, which probably can be done on every CPU with any cache at all --- and they've never seemed to be much of a big deal either.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#137So is today a good day to buy Intel stock?
Would say no. INTC has not been hit yet from this. Cramer this morning indicated the issue is unsubstantiated.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#138Earlier quoted context omitted.
There is this thing called "return oriented programming". You write your program as a series of addresses that are smashed onto the stack through some other type of vulnerability. When the current function returns, it returns to an address of your choosing. That address points to the tail end of some known existing function, such as in the C library and other libraries. When the tail end of that function returns, it…
Thanks for the explanation. But I don't understand this part: > If you could know all of the addresses of important kernel routines, you could potentially execute a "return oriented programming" attack against the kernel with kernel privileges. Without modifying or injecting any kernel level code. The user kernel transition is mediated (on x86-64) with the SYSCALL instruction, which jumps to a location specified by a…
Basically, let's say there's a syscall that takes a user buffer and size and copies it into kernel stack for processing. (This is common.) If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#139Earlier quoted context omitted.
Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our comp…
Where’s that quote from? ISTR reading it (or something very similar) as reported speech in a HN comment. Overall it’s a depressing story of predictable market failure as well as internal misbehavior at Intel, if true. Few buyers want to pay or wait for correctness until a sufficiently bad bug is sufficiently fresh in human memory. And if you do want to, it’s not as if you’re blessed with many convenient alternatives.
The quote is from the link above (referencing an anonymous reddit comment).
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#140I wonder what implications this will have on those who run Intel in their gaming rigs. I'm due to refresh, and _was_ gonna invest in Intel as my CPU. But this seems pretty damning for that. I assume the system calls to interact with the GPU, or to do any sort of I/O, are going to incur the performance overhead. So rendering frames, reading/writing from the network, and loading assets from the disk could all cause iss…
Apparently zero effect: https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-...
Well, that's for Linux. We don't exactly know what effects such patches would have on other platforms yet. (do we?)