I don't know much about CPUs, so what prevents a fix via microcode update?
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
151–160 of 567 posts
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#152Literally just read here yesterday how the CEO dumped majority of his shares. So Shiesty. https://news.ycombinator.com/item?id=16055851
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#153Earlier quoted context omitted.
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
#154Can 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'm cursed when it comes to timing. It's like when I bought that house in 2007, held onto it waiting for the market to recover, then tried to sell it only to find out my tenants had been using it to operate a rabbit-breeding business for years and completely trashed the place (thank you, useless property manager), forcing me to sell it at a loss anyway (6 months ago).
Also, I hate rabbits now. And I veered off topic, sorry.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#155This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…
Cloud services may not need to worry about the issue depending on the OS the customer choose to use, the patched or non patched version.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#156Earlier quoted context omitted.
> From what I've read, this slowdown only affects syscalls Incorrect. It also affects interrupts and (page) faults. Any usermode to kernel and back transition.
So this is evil for virtualization hosting, which is the major enterprise application for Intel chips. Hosting on bare metal will become more attractive. Too bad you can't long OVH and Hetzner.
What does that even mean?
Also Hetzner just introduced some AMD Epyc server.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#157Earlier quoted context omitted.
This is typically what happens when you go for a long time without real competition. You get way too comfortable and bad habits start to pile up.
But why do AMD chips not have similar issues? To me it looks like Intel tried to micro optimize something and screwed up.
> The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.
Out-of-order processors generally trigger exceptions when instructions are retired. Because instructions are retired in-order, that allows exceptions and interrupts to be reported in program order, which is what the programmer expects to happen. Furthermore, because memory access is a critical path, the TLB/privilege check is generally started in parallel with the cache/memory access. In such an architecture, it seems like the straightforward thing to do is to let the improper access to kernel memory execute, and then raise the page fault only when the instruction retires.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#158I 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…
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#159This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…
If people who received written assurance from Intel that their hardware is 100% bug free can form a legal class, sure. I highly doubt there is even a single one such customer.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#160I 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…
Though even if I lose some percentage, it will still outrun AMD on single core applications (and probably also multi core ones).