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."
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.
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.