I can only expect that future will be worse. It may be that VM providers will find it unprofitable to offer a VM capable of running generic native code. Another thing that security products for desktops like Qubes OS that rely on hardware isolation to run untrusted code may need to reconsider their business model.
What’s the connection between the performance hit of this bug and Qubes’ business model?
Serious Intel CPU bugs (2016)
81–90 of 110 posts
Re: Serious Intel CPU bugs (2016)
#82Can we put [2016] in the title? Thanks!
Re: Serious Intel CPU bugs (2016)
#83All the CPUs in my house are 4th and 5th generation Intel CPUs except for one PC laptop that has a Skylake processor. I guess I'm glad now that Apple put a 2 year old CPU in the early 2015 Macbook Pro! Besides my 2012 Mac Pro, that is the most expensive machine in the house!
Re: Serious Intel CPU bugs (2016)
#84Quote from article "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 competition is moving much faster than we are". Competition pressure could make a company's new product worse than (in this case, less stable than) their previ…
I look at a statement like "Our competition is moving much faster than we are" as craven and lacking vision. At that point a wisened old Zen master type figure should've stepped forward.
Competition isn't about imitating the competitor anyway, is it? It's about differentiation, right? Maybe not. But it's not like you can't easily market literally any reasonable decision you make. Paul Masson wineries bragged about selling "no wine before its time" and turned their lack of "velocity" into marketing cachet. (Even though they weren't even unique in that regard.) There's no theoretical reason why Intel couldn't market itself as "the accurate chipmaker," keep on validating "lavishly"(1) and let AMD rush headlong into this kind of bug.
(1) Obviously not... but unfortunately you never know it's not enough validation until it's not enough validation.
Re: Serious Intel CPU bugs (2016)
#85Earlier quoted context omitted.
What’s the connection between the performance hit of this bug and Qubes’ business model?
This bug can be worked around. But the next one may not, making hardware-based virtualization as a secure way to run unprivileged code with max native performance unworkable. I.e. longer term if one wants to run untrusted code, it cannot be native one so any bug can be fixed without replacing hardware.
It's a bit hard to parse that sentence, could you rephrase?
Are you saying that untrusted code should only be run on systems which do not use hardware virtualization, because there's a risk of hardware bugs that require hardware replacement? The problem is that there is no single-system equivalent, users would have to use multiple laptops/desktops and air gaps to achieve separation (e.g. between network drivers and userspace apps). May not be practical.
Yes there's a risk of a catastrophic hardware bug with no workaround, but that risk applies to every feature in the CPU, not only virtualization or page tables or speculative execution. Statistically it's only happened once with the single Intel CPU recall, which are better odds than other risks.
Re: Serious Intel CPU bugs (2016)
#86Denverton is much more complex than a "simple" Atom (performance of a C3958 is up to about half of an i5-7500 in single-thread, twice the total multi-thread performance). Avoton is really no slouch either. It's really not surprising that the incidence of bugs is increasing on those uarchs as the complexity grows. The Skylake/Kaby hyperthread bug has been fixed in microcode and is no longer applicable. It's perfectly…
>Gamers and compute-oriented workloads won't be hurt hardly at all. Actually KPTI doesn't only affect syscall but also interrupts. It makes interrups slower, which affects every workload.
Does this mean they could take a hit due to this bug?
Re: Serious Intel CPU bugs (2016)
#87What do you think, is this realistic?
Re: Serious Intel CPU bugs (2016)
#88Earlier quoted context omitted.
Can you back this up? I googled and didn’t find anything relevant.
Yes I can. https://www.amazon.fr/Economics-Software-Quality-Capers-Jone... Not all good content is offered for free on the Internet.
Capers Jones’ work does not “disprove” the triangle, and doesn’t even mention it. If anything, he implies that quality is a more complicated subject than the simple triangle implies, in that lower quality will have non-linear negative impacts on the project cost, time, and scope.
This is the triangle: https://en.m.wikipedia.org/wiki/Project_management_triangle
The original triangle assumes that as a PM, if you don’t recognize the trade off among scope, time, and cost, quality will suffer. This is true even with Jones’ data, but it is trite. The practices that help to ensure quality that are outside the triangle’s intent as a guideline: it is necessary to recognize these trade offs, but not sufficient, to ensure on-time, on-budget, sufficient quality and scoped delivery. One could manage tradeoffs among the time/cost/scope variables and still screw up their product’s quality due to poor methods and practices. Which is obvious, when you think about it.
Jones’ book also has a number of flaws - it’s hard to put his recommendations in practice (its more a survey than a “how to”), and he lacks data on a number of effective , newer practices that involve both quality, improved velocity, and requirements gathering or product/market fit. The result is that he tends towards promoting older practices that help quality but don’t have much impact on whether you’re building the right thing in the first place. To be fair, he admits this throughout the book, but being a data guy, shrugs and moves on to discuss what works with the data he has. A classic case of “looking for your car keys under the street lamp”. Nevertheless, it illustrates why quality pays for itself, which makes it important.
Re: Serious Intel CPU bugs (2016)
#89Earlier quoted context omitted.
>Gamers and compute-oriented workloads won't be hurt hardly at all. Actually KPTI doesn't only affect syscall but also interrupts. It makes interrups slower, which affects every workload.
Gamers like to use PS/2 peripherals because they're interrupt based and thus more responsive than USB peripherals. Does this mean they could take a hit due to this bug?
Edit: also "interrupt-based" in this case has nothing to do with interrupts seen by the CPU. Difference is that in ps/2 the device can send data to the controller (which then generates interrupt) at any time, while for usb the controller periodically polls devices for data (and possibly generates interrupt if there are some). In the early days of USB and UHCI host controllers this polling was done in software, but since USB 2.0 this is done in hardware and generates real cpu interrupts when usb device requests interrupt (although with somewhat unpredictable but bounded latency)
Re: Serious Intel CPU bugs (2016)
#90Earlier quoted context omitted.
Well depending on how this is turning out there will be benchmarks that show the chips performing slower than before. I've read that many chips will be getting 17% slower in the best case and up to 30% in the worst case. That could be enough to warrant a return of the product.
Yes, however most computers are marketed using GHz numbers, not experienced performance (And in the cases where they are it's relative, like x times faster than before). It's hard to show a 17% slowdown to a store clerk. Don't get me wrong, I'm all for being able to return a product that's 17% slower today than yesterday, I'm just saying it might be difficult since it's an issue that requires a degree of technical kn…