Live data from Hacker News

Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

perens.com

491–499 of 499 posts

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#491

Earlier quoted context omitted.

That is a horrifically biased & wrong summary. AMD enforce privilege checks at access time rather than at retirement time. Whether or not this is due to "lack of optimization" or "good security engineering" nobody knows. But your claims that this was purely the result of "less optimised [sic]" cores is nonsense. You have zero evidence whatsoever that that was the case vs. AMD just having superior engineering on this…

The summary is correct and optimised is the correct spelling where I'm from. If AMD were making conscious efforts to avoid side channel attacks they'd already have had various features to show for it like IBRS. But AMD's chips say nothing about side channel attacks. Their manuals do not discuss Spectre attacks. And there is no evidence anywhere that they knew about Meltdown type attacks and chose to avoid them. I get…

For meltdown AMD followed what the x86 spec said. It's flabbergasting you are trying to contort this into making AMD look bad. Your "summary" was basically that AMD was too incompetent to have multiple security issues.

The facts are AMD does not have a significant per-core IPC defeceit vs. Intel (as supported by every ryzen review at this point) and AMD has, on multiple occasions now, had objectively superior security.

You're trying to twist this into a negative against AMD. It's nonsense FUD. Intel fucked up, AMD didn't. Why are you trying to run PR damage control for Intel?

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#492
> I don’t know if Intel could have forseen the problem. Since some similar exploits have been discovered for AMD and ARM CPUs, the answer is probably “no”.

the answer is they probably both should have.

speculatively executing code that is time-sensitive to privileged data should have been caught. timing attacks on this level have been known for at least a decade. for that reason I don't quite believe that nobody at Intel (or AMD) was aware of the possibility of these attacks before anyone in the security industry published about it. they should have been more responsible instead of just waiting until it broke.

everything about this saga adds up to economics, business and production reasons why 1) not enough people were paid to look for these kind of problems, 2) the microcode developers that might have become aware of potential issues didn't have a good avenue to raise them, 3) there seems to have been NO proper roadmap whatsoever at both of these (rather large) companies for responsibly addressing, fixing and patching mistakes of this level. the whole response seems to be completely ad hoc, like it was some kind of one-in-a-million act-of-god thing that nobody could have foreseen.

it's not a super obscure bug. it's a side channel cache timing attack, the likes of which have been well-known for over a decade.

if Intel and AMD both thought, during the past decade, "well we know about side channel cache timing attacks now, and this is probably the worst they'll ever get", they don't know quite an important rule about security: exploits only get worse, never better. that inaction definitely doesn't fall under "could not have foreseen".

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#493

Earlier quoted context omitted.

That depends what you mean by mainstream. These days the cloud data centre is a mainstream market for hardware vendors. In that environment FPGAs can make sense. They might have advantages in throughput, latency, power consumption, security (no spectre), reliability (no software updates). For example, Microsoft use them for Azure virtual networking, machine learning and something inside Bing. You can imagine a world…

As far as know there are zero applications on the client or desktop side that can take advantage of FPGA.

There's this: https://docs.microsoft.com/en-us/azure/machine-learning/serv...

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#494

Earlier quoted context omitted.

Google and Facebook would look a lot different without transistors.

And lasers. And Unix. And switched networking. And binary digital computers. And long-haul undersea cables. And the first successful communications satellite. And data networking. http://blog.tmcnet.com/next-generation-communications/2011/0...

Yes, but apart from that, what have the Romans, er, Bell Labs ever given us?

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#495
post #351

Earlier quoted context omitted.

The right answer to this is to look into benchmarks. It now works again to compare Intel and AMD clocks, but only of the current generation, and then there is core count and motherboard prices to consider, so on. A project of mine is a hardware recommender, it also includes a meta-benchmark. I collect published benchmarks and build a globally sorted order of processors out of it. https://www.pc-kombo.com/benchmark/ga…

Can you add the ability to sort based on price/perf? Also, the existing bar graph is unclear to me. What does 10/10 mean?

Thought a bit more about this. What I can do is filter out all processors/gpus that are slower than cheaper processors. Proof of concept implementation: https://www.pc-kombo.com/benchmark/games/cpu?optimize=true. Those are essentially the best price/performance choices, with some restrictions as explained in the other comment.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#496

Earlier quoted context omitted.

The summary is correct and optimised is the correct spelling where I'm from. If AMD were making conscious efforts to avoid side channel attacks they'd already have had various features to show for it like IBRS. But AMD's chips say nothing about side channel attacks. Their manuals do not discuss Spectre attacks. And there is no evidence anywhere that they knew about Meltdown type attacks and chose to avoid them. I get…

For meltdown AMD followed what the x86 spec said. It's flabbergasting you are trying to contort this into making AMD look bad. Your "summary" was basically that AMD was too incompetent to have multiple security issues. The facts are AMD does not have a significant per-core IPC defeceit vs. Intel (as supported by every ryzen review at this point) and AMD has, on multiple occasions now, had objectively superior securit…

Please show me where in the x86 spec side channel attacks are discussed at all? They aren't.

I am really unsure where you're getting this from. Your reference to the spec makes me wonder if you really understand what Meltdown and Spectre are. They aren't bugs in the chips even though some such issues may be fixable with chip changes, because no CPU has ever claimed to be resistant to side channel attacks of any form. Meltdown doesn't work by exploiting spec violations or actual failures of any built in security logic, which is why - like Spectre - it surfaces in Apple chips too. Like Spectre it's a side channel attack.

I'm not trying to twist this into a negative for AMD: it's the other way around, you are trying to twist this into a positive for them, although no CPU company has done any work on mitigation of micro-architectural side channel attacks.

I'm simply trying to ensure readers of this discussion understand what's truly happening and do not draw erroneous conclusions about AMDs competence or understanding of side channel attacks. What you're attempting to do here is read far more into a lucky escape than is really warranted.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#497

Earlier quoted context omitted.

Same, I had bad experiences with the early Athlons and bought Intels after that, never had any stability problems. But now I'm seeing douchey behaviour from both Intel and nVidia. I've been a big fanboy because of the performance, but the business practises are becoming polarising, and AMD seems to have caught up or surpassed in performance terms. Plus, they handled the vulnerabilities disclosure much better (even a…

> AMD made their entire business model off copying (later licensing) Intel contracted AMD to second source their processors as a requirement for being in the IBM PC (requirement dictated by IBM). AMD existed long before their version of the x86, producing the venerable http://www.cpu-world.com/CPUs/2901/ which was widely used in minicomputers of the time. The amazing thing about the 2901 and family, was that the engi…

Huh, I didn't know that. I thought AMD started competing with Intel by cloning the 286 and beyond. Had no idea it was for the IBM PC contract.

I knew about 64-bit (Athlon 64, anyone?), but I've always heard x86-64 described as a kludge and an awful hack, not a well-designed architecture. The greater RAM accessibility and native execution of 32-bit code are advantages, but shortly thereafter Intel went multi-core, which seems to have done drastically more for system performance than x64 did.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#498
post #446

Earlier quoted context omitted.

Wikileaks is a Russian propaganda machine. They are only interested in Anti-America leaks, not all leaks.

Ya, there's a huge niche in the market for pro-American leaks.

Nobody is asking for "pro-American" leaks. Wikileaks tried to present itself as a unbiased source of leaked news, the moment they refuse to leak negative news about a nation or individual they are showing a bias.

If you go on Wikileaks right now and search "Russia" for 2012-2018, you get mostly news about how western plans are going to fail and how powerful Russia's military is. If you search for Russia in the "Syria Files" section, you get no results. How is that even possible?

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#499

Earlier quoted context omitted.

For meltdown AMD followed what the x86 spec said. It's flabbergasting you are trying to contort this into making AMD look bad. Your "summary" was basically that AMD was too incompetent to have multiple security issues. The facts are AMD does not have a significant per-core IPC defeceit vs. Intel (as supported by every ryzen review at this point) and AMD has, on multiple occasions now, had objectively superior securit…

Please show me where in the x86 spec side channel attacks are discussed at all? They aren't. I am really unsure where you're getting this from. Your reference to the spec makes me wonder if you really understand what Meltdown and Spectre are. They aren't bugs in the chips even though some such issues may be fixable with chip changes, because no CPU has ever claimed to be resistant to side channel attacks of any form.…

Meltdown was enabled by a clear-cut violating of the memory access restrictions of x86. Intel simply did the permission check at the wrong point in the pipeline. It's not anything more obscure or clever than that, and it wasn't even an optimization as the end-to-end latency remains the same. It still did all the work, it just did it in the wrong order. Permission check was done after read access was done anyway.

Memory was accessed that the spec says was not accessible. This has nothing to do with side-channels. The side channel part of the attack was how the spec violation was exploited.

For Meltdown specifically Intel fucked up, AMD didn't. This is not at all vague. Whether or not this was due to luck or not is irrelevant, it was clearly NOT due to incompetence as you were pushing. You pushed a narrative that AMD was too incompetent ("missing optimization") to have a severe security bug. That has nothing to do with reality whatsoever.

Side note, side channel attacks are not exactly obscure. Guaranteed AMD & Intel have security experts that are well aware of how side channel attacks work long before any of meltdown & spectre came to light. They have been around for ages. Practical exploits of L1/L2 cache via mechanisms like Prime+Probe date back at least as far as 2005: https://eprint.iacr.org/2005/271.pdf

Post reply on HN