4 ms·

what's interesting is that this isn't as serious as some of the issues today. just following the example, the result is wrong after the 4th digit. this is abso

by mpixel 3y ago

what's interesting is that this isn't as serious as some of the issues today. just following the example, the result is wrong after the 4th digit. this is absolutely 'could be handled in software with a significant performance loss' territory. that isn't to say this isn't breaking -- it absolutely is. what I'm getting at is that my CPU runs 30% slower with mitigations. if I were running multiple servers like the computer I use, and I was near the capacity of my resources, I would need to add some machine(s) -- and people do. in the same way this is serious, these current issues are the same yet somehow we've lost some stuff along the way and we just don't do recalls or even receive any remedies. where's my check?

mjg59 3y ago
For the most part, the bugs we've seen in recent history can be handled at the kernel level - there's largely no need for applications to care about them (browsers to an extent being a counterexample, but even then if you disable hyperthreading it can basically be ignored at the browser level). The floating point division bug was something that every single application would need to have handling code for. From a "What is the worst case outcome", the Spectre family of bugs may win. From a "What is going to require the most engineering effort to fix in software", fdiv would probably have been a much bigger deal.
- nextaccountic 3y ago
  One option would be to have an x86 to x86 compiler that automatically fixed your code. In principle you don't need access to source and it could be shipped by the OS
dustfree_mt 3y ago
UVM, formal verification, co-simulation through DPI were at their infancy back then, thus such silly(albeit critical) errors kept popping up and were really hard to catch during pre/post-silicon testing. You can't catch spectre or similar things where multiple blocks all doing the wrong thing together with UVM or formal nowadays either(too large search space), so I'm eager to see what kind of top-level verif. methodologies people will invent as the designs grow larger and larger.
rvba 3y ago
I have this theory that Intel knew very well what they were doing by cutting corners everywhere. This way their processors were simply faster than the ones manufactured by AMD. But it was "fake" advantage (due to ignoring bugs) - now that those bugs come out to light, their processors are slower. But were already sold. And yes I know that AMD has some similar bugs. The US government will not go after Intel though due to public safety issues - they want their processors to be manufactured at US soil (different thing is if they are really safe with all those bugs and spying features, also are they even manufactured inside USA anymore?). Other governments could go aftet Intel though.
- hardware2win 3y ago
  >And yes I know that AMD has some similar bugs. So, how does your theory stand? If we assume that both companies were cutting corners and one was ahead, then?
  - planede 3y ago
    Until they got caught out on it competition on performance incentivized both to cut corners on side channel attack surfaces.
  - dfhanionio 3y ago
    Intel was vulnerable to Meltdown and Spectre. AMD was only vulnerable to Spectre. Meltdown arose because vulnerable designs delay memory protection checks until as late as possible, after illegal accesses could have already affected state. This is a questionable decision, as it is playing fast and lose with the most fundamental building blocks of security. Most companies wisely chose a more cautious approach. If an investigation found that watermelon is carcinogenic, that would be a problem. If that same investigation found that Andy's Farm sells watermelon that contains benzene, Andy's Farm couldn't defend itself by saying all watermelon is carcinogenic.
- h2odragon 3y ago
  I've had a notion for years that Intel has intentionally failed to pursue some areas of performance improvement so as to reserve them for "official" users. way, way back at the beginning of the PC revolution, for example: SRAM vs DRAM? Intel went all in on DRAM. Imagine how different the world could be today if they'd chosen differently an could expect all main RAM to be "cahce latency". DRAM would be a slower dynamic store, possibly looking more like hard drives did. What if they'd decided that unifying a bus was a good idea instead of tossing out new ones every couple years? Imagine the longevity and variety of the VME bus ecosystem couples with the size of the PC market, in the 80s.

by mpixel 3y ago

mjg59 3y ago

For the most part, the bugs we've seen in recent history can be handled at the kernel level - there's largely no need for applications to care about them (browsers to an extent being a counterexample, but even then if you disable hyperthreading it can basically be ignored at the browser level). The floating point division bug was something that every single application would need to have handling code for. From a "What is the worst case outcome", the Spectre family of bugs may win. From a "What is going to require the most engineering effort to fix in software", fdiv would probably have been a much bigger deal.

nextaccountic 3y ago
One option would be to have an x86 to x86 compiler that automatically fixed your code. In principle you don't need access to source and it could be shipped by the OS

dustfree_mt 3y ago

UVM, formal verification, co-simulation through DPI were at their infancy back then, thus such silly(albeit critical) errors kept popping up and were really hard to catch during pre/post-silicon testing. You can't catch spectre or similar things where multiple blocks all doing the wrong thing together with UVM or formal nowadays either(too large search space), so I'm eager to see what kind of top-level verif. methodologies people will invent as the designs grow larger and larger.

rvba 3y ago

I have this theory that Intel knew very well what they were doing by cutting corners everywhere. This way their processors were simply faster than the ones manufactured by AMD. But it was "fake" advantage (due to ignoring bugs) - now that those bugs come out to light, their processors are slower. But were already sold. And yes I know that AMD has some similar bugs. The US government will not go after Intel though due to public safety issues - they want their processors to be manufactured at US soil (different thing is if they are really safe with all those bugs and spying features, also are they even manufactured inside USA anymore?). Other governments could go aftet Intel though.

hardware2win 3y ago
>And yes I know that AMD has some similar bugs. So, how does your theory stand? If we assume that both companies were cutting corners and one was ahead, then?
- planede 3y ago
  Until they got caught out on it competition on performance incentivized both to cut corners on side channel attack surfaces.
- dfhanionio 3y ago
  Intel was vulnerable to Meltdown and Spectre. AMD was only vulnerable to Spectre. Meltdown arose because vulnerable designs delay memory protection checks until as late as possible, after illegal accesses could have already affected state. This is a questionable decision, as it is playing fast and lose with the most fundamental building blocks of security. Most companies wisely chose a more cautious approach. If an investigation found that watermelon is carcinogenic, that would be a problem. If that same investigation found that Andy's Farm sells watermelon that contains benzene, Andy's Farm couldn't defend itself by saying all watermelon is carcinogenic.
h2odragon 3y ago
I've had a notion for years that Intel has intentionally failed to pursue some areas of performance improvement so as to reserve them for "official" users. way, way back at the beginning of the PC revolution, for example: SRAM vs DRAM? Intel went all in on DRAM. Imagine how different the world could be today if they'd chosen differently an could expect all main RAM to be "cahce latency". DRAM would be a slower dynamic store, possibly looking more like hard drives did. What if they'd decided that unifying a bus was a good idea instead of tossing out new ones every couple years? Imagine the longevity and variety of the VME bus ecosystem couples with the size of the PC market, in the 80s.