AMD Immune to MDS Vulnerabilities
tomshardware.com
tomshardware.com
Synthetic benchmarks can get you a penalty from anywhere from 1.001x and beyond 2x.
Your workload also influences which mitigations you can safely turn off. If you're running a single-tenant system and don't need isolated security domains then you can turn them off.
Future software improvements (io_uring!) may also recover some of those losses.
This is the dirty secret that no one will let out because its ramifications on "the cloud" are very serious, and Microsoft, Amazon, et al have staked their futures on rent-seeking via cloud.
These hardware bugs make the risks of multi-tenancy incontrovertible, and I would expect enterprise security departments to be clamoring for the return of hardware control.
My popcorn is out to watch as the frantic inquisition against cloud heretics kicks into high[er] gear.
While single-tenant options may be available for some configurations, you'll pay through the nose, and there are many limitations (e.g., EBS-backed volumes attached to your single-tenant instances still run on multi-tenant hosts). Moreover, few if any of the managed cloud services, which are what really drive cloud adoption, have any concept of single tenancy.
Even after all this, the risk is only partially mitigated, because you're trusting Amazon's management toolkit and staff to respect these boundaries and to not have any bugs that may inadvertently expose access or data to third parties. Considering single-tenancy is such a small segment of their business, I doubt this is a major consideration, and even if it is, it's a lot of eggs to put into a basket that's completely out of your control.
There just isn't much of an argument for a group that's serious about security to commit hardcore to "the cloud", yet virtually every company I've encountered in the last few years is pushing this hard, and actively ostracizing anyone who tries to inject some moderation or sanity into it.
I appreciate the convenience of cloud offerings as much as the next guy, but it's out of control, and the complete disregard for the implications of hardware bugs that fundamentally undermine the supposed security model is a great representation of that.
> On Linux distributions like Ubuntu 18.10 and Clear Linux the mitigation costs were about ~18% while both RHEL 8 Beta and openSUSE 15.0 had a nearly 40% hit.
If we look at MDS mitigation for older MACs[2], it could be 40%:
> Intel MDS Vulnerabilities Affecting 7th Gen And Below May Slow Macs By Up To 40%, Apple Warns
If we look at MDS mitigation generally (if Intel is to be believed) we are looking at ~10% for most use cases[3]
> Intel's benchmarks show a 6-14 percent drop in storage performance on a couple of Xeon processors, both with Hyper Threading enabled. Assuming that Intel is not showing a worst case scenario in any of these benchmarks, the hit to storage could be even bigger.
> It's in workstations and data centers that mitigations are likely to have the biggest performance impact, depending on the workload. In a separate graph, for example, Intel shows a 19 percent drop in "server side Java" performance after disabling Hyper Threading on a Xeon Platinum 8180 processor (compared to having it turned on).
In other words... total I have no idea what we'll be seeing. However, if we don't look at just "raw performance" in benchmarks when buying CPUs, AMD is likely a better purchase for most use cases at this point.
[1] https://www.phoronix.com/scan.php?page=article&item=spec-mel...
[2] https://wccftech.com/intel-mds-vulnerabilities-affecting-7th...
[3] https://www.pcgamer.com/intel-posts-benchmarks-showing-perfo...
https://www.phoronix.com/scan.php?page=article&item=mds-zomb...
Not looking good for Intel at the moment. It should also be noted that there's believable rumors that the mitigations are not fully effective unless hyperthreading is disabled.
Rough prices I just googled: Core i7 8700K is $390, Ryzen 7 2700x is $290, Core i9 7980XE is $1800 and Threadripper 2990WX is $1600.
Right now there aren't any site putting those number with AMD's number next to them.
May be it is too much work and they will wait for the new Ryzen arrives.
It appears as if nobody at Intel is doing anything other than cursory security analysis of processors. So far the cost has been performance, but I imagine there may be some bugs without micro-code mitigation. Not only this but it appears to be only a matter of time until Intel ME is broken too.
We now have AMD Ryzen CPUs combined with nVidia dGPU solutions, unthinkable just a year ago. I'm still waiting for the Ryzen 3750Hs to hit the (German) market, but if I had to buy tomorrow, I'd presently opt for the Asus FX505DT-EB73. This one has an NV dGPU, there's also an arguably Linux friendlier AMD RX 560 of that laptop available, too.
I personally would also prefer an AMD dGPU solution, but the RX 560/580 is already old and I don't think AMD has a solution anytime soon either, unfortunately...
The built-in Radeon Vega 8 or 10 solutions on all mobile Ryzens are usually better and more efficient than current Intel counterparts, so if you don't need a dGPU, then that's one more reason to root for Team Green.
EDIT: In case anyone reading isn't aware, nVidia is a biaaatch when it comes to drivers for Linux. Anyone looking for powerful GPUs in Linux machines, no matter desktop or laptop, has an easier life with AMD solutions. That's the reason there's an infamous photo of Linus showing the finger to nVidia: https://www.youtube.com/watch?v=IVpOyKCNZYw
When it comes to normal consumer hardware, it seems that nVidia drivers for Linux in 2019 are still a hit and miss:
https://www.reddit.com/r/linux_gaming/comments/bhfjnb/nvidia...
https://www.reddit.com/r/linux_gaming/comments/bol5uo/nvidia...
EDIT: Maybe my formulation of "powerful GPUs" led you on to that. Though I did say "no matter desktop or laptop" to clarify that...
No, "nvidia is a biaaatch" led me. I just stated that my experience is different. How about you share your actual experience?
I might be biased as I used GPUs for scientific computations and Nvidia reached level where it "just" works on Linux many years ago.
Also: * Steam and few games I have on my laptop (ubuntu) with nvidia mobile graphics work fine.
* My home workstation (gentoo) and workstation at work (ubuntu) also work fine.
as a matter of fact, there is no need to install said binary as its most likely already upstreamed to your distribution of choice.
but nvidia still reigns supreme if we're talking actual performance ... at least after you've installed said binary blob ;)
and i can say from personal experience that the nvidia 10x0 drivers were terrible in the first ~6 month after their release. fan kept jumping between 10-80% for example. Haven't had any issues in at least a year though, but i'd expect the same kind of issues on any new chipset by nvidia, as they havent open sourced their drivers
If you can, build a gaming PC instead; you'll have a more powerful and more upgradeable machine for a fraction of the money (as low as $600[0]). And it'll likely work. In my experience, gaming laptops don't work. Laptops in general don't work, but especially gaming ones and especially for gaming. Ironically, this gets truer the more expensive a laptop is, which is the opposite for PCs.
And yes, it really needs to be a gaming laptop, I travel for work, and I have had good experiences gaming on the go. It's still a relief to get back home to the desktop, no doubt, but I'm often gone for two days to two weeks, and I'd still like to be able to pull a few frags in that time... :D
I'm currently using an Intel 4702MQ with a GTX 760M in an Acer package, she used to be fine to play CSGO, but that's no longer the case either...
If all the VMs do is waiting for a network packet 99.9% of time, then not so much.
I'm looking forward to the upcoming T495s that drop the A moniker to replace my y700.
- Older models: Acer Swift 3, HP Envy x360 and Lenovo IdeaPad 720S, Thinkpad e585
- Newer models: Thinkpad T495 (and T495s), Lenovo Flex 14, Asus VivoBook F512, Honor Magic Book 2019 Ryzen
I've had great linux experiences with Asus and Thinkpads in particular. Mixed but recently better with HP and Acer. No experience with Huawei/Honor.
I'm building a PC, initially wanted to use Intel because of hackintosh. But I don't think it's justified to have an already expensive CPU (Intel is more expensive than AMD) gets throttled down again due to patches.
So now I'm considering AMD. What would you recommend for developer? I will use it for Android, Docker and occasionally gaming.
(I'm aware that I most likely won't have hackintosh due to AMD)
That said the Zen 2 (3rd generation) is out a in a few months so depending on urgency you may want to wait for the 3xxx series.
They moved to 7nm and the IPC bump is supposed to be decent.
If it's still too much a Ryzen 5 2600(X) (6 cores) is still a very good processor for almost any use case.
About hackintosh and AMD, that's is not only possible, but also not too complicated to achieve on Mojave (see https://vanilla.amd-osx.com/ for more details). Older versions required using custom AMD kernels, but some guy figured out how to patch the vanilla kernel for Ryzen and Bulldozer straight from Clover; it's not as simple as using Intel, but it's much easier than it was a few years back.
https://www.phoronix.com/scan.php?page=news_item&px=Spectre-...
Monocultures invite epidemics.
It's also possibly significant that Linux on servers is split between Redhat and Ubuntu and others, who have some non-trivial differences in regards to security updates, etc.
None of which means that Unix-based OS's don't have inherent advantages in regards to security, just that not having a monoculture target on their forehead also helps.
While it's by no means a guarantee, it does say something about the engineering culture that they understood the theoretical risks of violating a protection barrier and chose to respect those boundaries, instead of dismissing the risk and going for the bigger stats. That deserves notice and approbation.
This is particularly bad for Intel because most of the SMT-based exploits can pretty much only be mitigated by disabling SMT entirely and taking such a substantial performance hit that they've been trying desperately to convince people not to.
AFAIU OpenBSD uses it for W^X (aka DEP) on i386. Linux may, too.
If anything the bet was crazy, regardless who is affected.