Slashdot Mirror
Researchers Discover Seven New Meltdown and Spectre Attacks (zdnet.com)
A team of nine academics has revealed today seven new CPU attacks. The seven impact AMD, ARM, and Intel CPUs to various degrees. From a report: Two of the seven new attacks are variations of the Meltdown attack, while the other five are variations on the original Spectre attack -- two well-known attacks that have been revealed at the start of the year and found to impact CPUs models going back to 1995. Researchers say they've discovered the seven new CPU attacks while performing "a sound and extensible systematization of transient execution attacks" -- a catch-all term the research team used to describe attacks on the various internal mechanisms that a CPU uses to process data, such as the speculative execution process, the CPU's internal caches, and other internal execution stages. The research team says they've successfully demonstrated all seven attacks with proof-of-concept code. Experiments to confirm six other Meltdown-attacks did not succeed, according to a graph published by researchers. Update: In a statement to Slashdot, an Intel spokesperson said, "the vulnerabilities documented in this paper can be fully addressed by applying existing mitigation techniques for Spectre and Meltdown, including those previously documented here, and elsewhere by other chipmakers. Protecting customers continues to be a critical priority for us and we are thankful to the teams at Graz University of Technology, imec-DistriNet, KU Leuven, & the College of William and Mary for their ongoing research."
...This wasn't the best way to improve performance. There are other approaches, or modifications to existing ones.
Does anyone know if Itanium 3 was affected? If not, Intel might want to revisit it, as there's bound to be commercial interest in fast, secure processors. (Because it was a ground-up redesign, it would have been free of defects from mainstream processors.)
I'm guessing the UltraSPARC/T3 is safe, for similar reasons. Totally different internal architecture.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
https://zdnet1.cbsistatic.com/hub/i/2018/11/14/15e46793-eebf-46b5-8fbd-23896b34a1ae/9641c5228c53fbde1d8778dd94ae5832/new-meltdown-attacks.png
Not that quantity of vulnerabilities is everything but Intel and Arm are in serious relative trouble... again. How many of their performance and power advantages over the last several years have been substantially due to the of taking secure design shortcuts? AMD may be even further than the lead than we've realized.
Do you have proof that a powered down computer in the box is actually secure? After all, they have batteries and some components are active.
For the majority of users, we could be doing fine with computers from 1998 if the operating systems, applications and the Web had not suffered so much bloat, especially because of the overuse and bloat of using multiple javascript librairies because web monkeys are too lazy to write their own five lines functions in javascript.
The only regular users who need so much computing power are gamers, where security is not exactly critical.
Then there is an extreme minority of users and datacenters who need both security and computing power, but those are specialized users and should move to a different architecture.
#DeleteFacebook
This is more the problem. I've known both flavors or software devs, code monkey or genuine talent, and while obviously you want the later they both face the same issues. The number one issue for code optimization is time constraints. Until the performance of the code actually becomes a problem and there is significant monetized benefit to improving the underlying architecture/design/implementation no one in management is really going to care if the dev got the algorithm to run in O(n) or O(logn). The questions they ask are simply does it work, is the customer ok with how it works, and how fast can you give it to us/them to buy/sell?
I remember one piece of code I managed to write on a project that I was actually extremely proud to have written. It was a completely proprietary need, so it had to be done in house with no libraries and was a very core piece of the service I was creating. I was able to do O(1) insertions, keep it self sorting for easy traversals, and perform O(1) lookups while it cleaned itself up. It even had a very minimal spatial complexity because I managed to do some wonderful pointer magic (in .NET at that) with a few different data structures. Once I completed the service I was actually satisfied with the implementation and that part of the code didn't have to be touched again (ever from what I was told by a few other project leads years later). You know what the project manager said? He didn't care at all and was actually upset that I didn't finish it early so I could work on the other developer's pieces because they were going slower than he wanted (I was even on time with the delivery and still got that response). Upper management sided with him and to avoid further friction moved me to a different project and threw a code monkey onto their team that spat out hot garbage...
I think if you talk to most good developers they probably have a similar story if they have been in the industry for more than 5 years or so. Scope creep and the insatiable desire for new tangible features are the biggest enemies to efficient and optimized code these days. We probably have just as many genuinely talented developers in the industry as ever imho.