An Update on AMD Processor Security | Hacker News Reader

An Update on AMD Processor Security

amd.com

192 pointsDeimorz35 comments

> Resolved by software / OS

It's not resolved by, it's mitigated by.

Furthermore, it wasn't mitigated by AMD (or Intel or ARM), it was mitigated by OS / Software vendors that had to spend the time to make workarounds for the hardware's design flaw. It would have been nice to see a nod to such developers for taking the time to help with the problem.

This could be an extinction level event for less popular OSes. Intel, and to a lesser extent AMD, may end up causing enormous damage for which they'll pay nothing much.

That's an excellent point. I used to work porting a commercial embedded real-time OS. I just reviewed the description of the recent mitigations in Linux.

It is easily 6 man-months of work if not double, and the level of expertise necessary to implement this right is pretty high. For a small OS shop, that's a pretty high price.

> ...it was mitigated by OS / Software vendors that had to spend the time to make workarounds for the hardware's design flaw

Free Software projects don't necessarily work like this. It's possible for CPU manufacturers to have taken the lead in the work in Linux, for example. Even just helping (which they have clearly done) is more of a nod than just a nod.

This response is better than the corporate speak Intel put out regarding these vulnerabilities. Still light on details, but at least not the same kind of corporate drivel.

AMD does not even mention Intel or ARM. While Intel did. Why is that? AMD mentions it's an issue with speculative execution used in modern processor architectures. Clean and simple, and to the point.

Here's Intel's response compare: https://newsroom.intel.com/news/intel-responds-to-security-r...

>As always, AMD strongly encourages its customers to consistently undertake safe computing practices, examples of which include: not clicking on unrecognized hyperlinks, following strong password protocols, using secure networks, and accepting regular software updates.

Ummm none of these things will stop this attack.

Except they just said this attack is virtually impossible (certainly hasn't been demonstrated) on AMD. So I interpret this as general advice.

Is the JS PoC for Spectre not applicable to AMD then?

I think Spectre and the JS PoC are actually the ones applicable to any modern processors (including AMDs, ARMs and probably most other chip vendors). Looks like the mitigations for these will be directly included in the browser.

EDIT : I don't even think we know of a way to fix Spectre in the kernel...

https://lkml.org/lkml/2018/1/3/780

No, that's only for variant two. Spectre is also variant one.

There are 3 attacks, two of which AMD claims to be immune/virtually immune to, and one which they do admit to being applicable.

These are all ways of preventing malicious code from running on your system. If you're not running code that abuses the new attack vectors, then you are effectively stopping the attack.

Still happy that i went with ryzen for my recent machine. I was sick of intel behavior then, only more so now.

I'm not sure what behavior with regards to this bug that you're referring to. From what I heard, Intel is freaking out and trying to fix things. Did I miss something?

Unrelated to the exploit, am pretty sure he's referring to the questionable anti-competitive practices Intel has engaged in the past decade.

Notably, the exclusivity-kickback agreements they arranged with several PC manufacturers. https://www.nytimes.com/2017/09/06/business/intel-eu-antitru...

As well as making their compiler choose the slowest execution path possible once it identifies it's running on an AMD/non-Intel CPU. http://www.agner.org/optimize/blog/read.php?i=49#49

That, the drm stuff, the spying, and the lack of innovation. Amd's more-cores approach really appealed to me.

Completely off-topic now, but I've had such a bad experience with the motherboard selection. So many bugs in even the most popular motherboard (X399 Taichi) that have necessitated countless updates, and the bug reports are still coming in.

At least with Intel, I could grab a server-class motherboard and guarantee rock-solid feature implementation - with the selection of AMD motherboards available we have even separate yet contradictory settings exposed in the BIOS setup. Pathetic.

What bugs have you observed in the X399 Taichi? Coincidentally, I have the same board (since TR launch) and haven't even updated the BIOS -- it just works fine for me.

I had to update my Taichi to support my RAM at full speeds, but other than that, it has worked generally well. My system overall sometimes does not wake back up after going into power save, but I am not sure that is the MB or if it is something else.

> I had to update my Taichi to support my RAM at full speeds

Unsupported hardware is hardly a bug.

I agree, I don't really think it was a bug at all- I was just commenting that I had only needed to update it that once for that one reason, and other than that, it has worked well. Though given the context, I can see how you might interpret my comment that way :)

Of course it is. If hardware A is built to a standard S and hardware B claims to fully support that same standard, then issues with A on B are 100% a bug in either A or B.

Version 2.0 exposes options for the following on two or more different pages that are not kept in sync and there’s no indication which is followed:

* power status after ac power loss * SATA ahci mode enabled * DDR speed * advanced ram timings * enables NICs * cpu overvoltage enabled * iommu enabled status

And others I’m forgetting.

X399 IOMMU support is completely broken, as well as ASPM. These options must be disabled to even successfully install Windows 10.

The X399 Taichi bios shows me tons of options for hardware/controllers that aren’t even physically present.

These motherboards cannot run RAM at the rates speeds due to the infinity fabric design. Look at the compatibility list AsRock published. They cannot achieve 2666MHz without jumping up to ram rates for 3200MHz, if I recall correctly. That’s because X399 is built as two separate sockets that happen to share a heatspreader and lga connection, and the interconnect operates at the same speed as the ddr bus; it just can’t keep up with tight timings.

After updating to Firmware v2, 4/5 Times the bios says “no connection” when trying to check for online updates (despite the wired connection in both ports plus a 10gbe pcie card), and a full power cycle is needed to try again.

This is the first chipset I’ve seen that won’t let me run a stick of ram at a slower speed (but it let me run other ram at slower speeds, so I’m not sure why) and fails to post if I set my ram to less than the XMP 2 setting manually.

The bios is built for gamers and overclockers. The options to enable OC are “auto” or “manual” and there is no “stock” or “disabled” option.

This wasn’t a platform built for stability. Motherboard manufacturers are treating ThreadRipper as if it were Ryzen, as if we were all gamers and this wasn’t a workstation chipset.

Intel lets you run Core i7 on its server boards. AMD won’t let me use a motherboard sold for Epyc with my ThreadRipper CPU. Nor should they have to.. except my current options are all crap.

My biggest problem of all is that X399 (not just the Taichi) randomly stops recognizing certain PCI-E cards. My PCI-E 10gbe x520-da2 NIC worked ok for a couple of weeks hen suddenly wasn’t seen any more. I thought it was the card and bought a new one. Same problem. I thought it was the os so I installed another. Same problem. I thought it was the bios so I reset it. Same problem. I manually toggled each option pertaining to PCI in the bios and rebooted to test between each one. Same problem.

Took a look on NewEgg. All the x399 boards have 3 star reviews at best, and are filled with similar PCI-E complaints and “worked for a month then stopped working” across all the manufacturers and models. Which isn’t saying much, since there are only a dozen or so, really.

> Resolved by software / OS updates to be made available by system vendors and manufacturers.

Not unless you update every piece of code running on your machine to insert an lfence following every branch on attacker-controlled data.

Care to explain? How is an OS update insufficient?

Fences in the code significantly slows down execution. While you can not avoid them altogether (modern processors are not sequentially consistent), the less you can use, faster your concurrent code is.

This update makes the kernel insert fences into places where it wouldn't have been necessary before, leading to potentially severe slowdowns.

I note they didn't state anything along the lines of "Negligible performance impact. In line with other hardware manufacturers such as Intel, our security fixes rarely cause severe performance loss."

Why would they? The performance loss being discussed on HN and affecting AWS and others is primarily for the 3rd variant, not the first (which your quote was with regards to).

Intel tacitly threw them and ARM under the bus, IMO, when Intel named them specifically and unnecessarily. It seems AMD do not wish to return the favour.

Computer security, what a nightmare. If governments backdoors were illegal to implement, that would help a little...

What are the "architecture differences" that make AMD CPUs immune to the 3rd variant (Rogue Data Cache Load, aka Meltdown)?

I found this explanation in a Linux kernel commit:

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...

Discussed on Hacker News at https://news.ycombinator.com/item?id=16052451 .

Thanks!

Reply on news.ycombinator.com