Earlier quoted context omitted.
Forgive me my ignorance, but I fail to see how this is such a big deal. Even 50% performance hit/cost increase would be... bearable, computations are rather cheap today. ML and other intensive calculations aren't done on CPU anyway. It's not like technical progress of our civilization is slowed down by 30% or something... On the other hand, shrinking Intel's market share due to bad PR and thus adding some competition…
If you run things efficiently you're eaking every ounce of performance out of this hardware. A 30% performance hit means a 30% cost increase. The bigger issue is for things that don't scale easily. That sql server that was at 90% capacity is suddenly unable to handle the load. Sure that could've happened organically, but now it happens (perhaps literally) overnight for everyone all at once. Expect a bunch of outages…
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
391–400 of 567 posts
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#392AMD stock price was higher in July and October. It increased a tiny bit and does not constitute “soaring”.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#393Earlier quoted context omitted.
Forgive me my ignorance, but I fail to see how this is such a big deal. Even 50% performance hit/cost increase would be... bearable, computations are rather cheap today. ML and other intensive calculations aren't done on CPU anyway. It's not like technical progress of our civilization is slowed down by 30% or something... On the other hand, shrinking Intel's market share due to bad PR and thus adding some competition…
I think you're vastly underestimating the potential impact to cloud providers. Azure/AWS/GCP all definitely have extra capacity, but they have forecasting down to a science. Requiring even 10% more capacity is quite a large undertaking alone.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#394Earlier quoted context omitted.
So a cloud provider would be an example. Compressible similar to a sparse file I guess as well. Thanks this makes sense.
I think it was meant that a normal application does not utilise the CPU all the time, which can be seen by looking at the task manager CPU usage % = X. Any extra processing needed to fix this bug will have to come out of the remaining 100-X%. This is OK as long as you have enough spare %, and can afford the extra power usage for that processing.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#395Earlier quoted context omitted.
Yep, this is getting blown way out of proportion by all of these tiny scripts that just sit around connecting to themselves. Even pgbench is theoretical and intended for tuning; you're not going to hit your max tps in your Real Code that is doing Real Work. In the real world, where code is doing real things besides just entering/exiting itself all day, I think it's going to be a stretch to see even a 5% performance i…
I think 5% is a reasonable guess for a database. Even a well-designed database does have to do a lot of IO, both network and disk. It's just not a "fixable" thing. But overall, yeah.
The reality is that OLTP databases execution time is not dominated by CPU computation but instead of IO time. Most transactions in OLTP systems fetch a handful of tuples. Most time is dedicated to fetching the tuples (and maybe indices) from disk and then sending them over network.
New disk devices lowered the latency significantly while syscall time has barely gotten better.
So in OLTP databases I expect the impact to be closer to 10% to 15%. So up to 3x over the base case.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#396I will eat my hat if that 30% number holds up.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#397Can 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…
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…
ASLR, PIC (position independent code: chunks of the binary move around between executions), and RELRO (changing the order and epermissions of an ELF binaries headers: a common ROP pattern is to set up a fake stack frame and call a libc function in the ELFs Global offset table) are all mitigations against ROP, but none solve the underlying problem.
The reason ROP exists is that x86-64 use a Von Neumann architecture, which means that the stack necessarily mixes code (return addresses) and data. The only true solution is an architecture that keeps these stacks separate, such as Harvard architecture chips.
As for bypassing the aforementioned mitigations...
ASLR: Only guarantees that the base address changes. Relative offsets are the same. So to be able to call any libc function in a ROP chain, all you need is a copy of the binary (to find the offsets) and to leak any libc function address at runtime. There are a million ways for this data to be leaked, and they are often overlooked in QA. Once you have any libc address, you can use your regular offsets to calculate new addresses.
PIC: haven't yet dealt with it myself, but you can use the above technique to get addresses in any relocated chunk of code, but I think you'll need to leak two addresses to account for ASLR and PIC.
RELRO: This makes the function lookup table in the binary read only, which doesn't stop you from calling any function already called in the binary. Without RELRO, you can call anything in libc.so I think, but with RELRO you can only call functions that have been explicitly invoked. This is still super useful because the libc syscall wrappers like read() and write() are extremely powerful anyway. Full RELRO (as opposed to partial RELRO) makes the procedure linkage table read only as well, which makes things harder still.
If this is the kinda thing that interests you, I heartily recommend ropemporium.com which has a number or ROP challenge binaries of varying difficulty to solve. If you're not sure where to start, I also wrote a write-up for one of the simpler challenges [1] that is extremely detailed, and should be more than enough to get you started (even if you have me experience reversing or exploiting binaries)
Disclaimer: I'm just some dipshit that thinks this stuff is fun, if I've made a mistake in the above please let me know. I also haven't done any ROP since I wrote the linked article, so im probably forgetting stuff.
[1] https://medium.com/@iseethieves/intro-to-rop-rop-emporium-sp...
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#398Earlier quoted context omitted.
Their competitors are also affected. Also a 30% decrease is also equivalent to setting Moore's law back 7 months. A 5% loss is only setting it back 1 month. I know that's a bit of a naive calculation. But the point is computing power has long operated in an exponential domain. So big differences in absolute numbers aren't necessarily a big deal.
According to this patch comment, AMD x86 chips are not affected: https://lkml.org/lkml/2017/12/27/2
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#399Earlier quoted context omitted.
Man, you should see the errata for some ARM-based SOCs. It's amazing that they work at all. Vendor, in conversation: "We're pretty sure we can make the next version do cache coherency correctly." Me (paraphrased): "Don't let the door hit you in the ass on the way out." Management chain chooses them anyway, I spend the next year chasing down cache-related bugs. Fun.
ARM is such a shitstorm. At least the PC with UEFI is a standard. With every ARM device, you have to have a specialized kernel rom just for that device. There have been efforts made on things like PostmarketOS, but still in general, ARM isn't an architecture. It's random pins soldered to an SoC to make a single use pile of shit.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#400Earlier quoted context omitted.
It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…
Problem is, most companies that need a lot of power only care about one thing - peak performance. And they tune it carefully in order to not overspend while guaranteeing minimal downtime. This means that they'll have to pretty much scale their infrastructure up by exactly 30%. That's a LOT for these big clients. Honestly, I'd just make sure the server firewalls are super tight and not take in the future patches. At l…