Hello anons. In regard to recent news today I want to have a more serious discussion regarding the 23-year-old vulnerability found within x86 architecture regarding 'memory leaks' and how this will affect our future investments as consumers towards any CPU from anyone. This is meant to be neutral towards both AMD and Intel. With that in mind, here are the facts we generally know. >Linux discussion forums discuss recent moves to patch security flaws >somebody sniffs this out and posts to the register >more information arises as x86 architecture is said to be affected for ARM, AMD, and Intel as said by Google's project zero team >Intel writes a letter for their investors ensuring the lack of severity of the issue and how it will be dealt with >AMD severely downplays any flaws in security stating for the most part that their CPU's are unaffected >5-30% cuts in performance for current products are announced regarding the upcoming patches for Windows and Linux kernels. >Linus writes a letter about Intel suggesting two different results of this latest news release
What is not known (at least to me) >how much this really impacts data centers, home computing, Commercial infrastructure, and government security worldwide. >how exactly AMD and ARM is affected by this security flaw and how severe it is for Ryzen/Ryzen2 >What will be done in the future to physically stop this security issue without sacrificing incredible amounts of performance compared to previous generations before the upcoming "patch"
Anyone with a background in computer engineering or advanced knowledge in Operating Systems would be appreciated for input. I want a little more /sci/ tier brain cell count on this board.
AMD doesn't just severley downplay the effects, they outright state that their CPUs have a "near zero risk" of exposure to the vulnerabilities.
Nathaniel Miller
>I want to have a more serious discussion lmao too bad, POST ANIME AND INSTALL GENTOO. >>>/reddit/
Aaron Hall
I can give you a little bit about Commercial Infrastructure, at least on logistics and transport companies. Many of them use ARM devices because the main purpose is to get shit moved, so you want something as small as possible.
Isaiah Turner
I want to know what will happen to Amazon GovCloud. Those guys run a cloud specifically for US Government customers that have high security requirements. They might actually be the first datacenter group to consider switching entirely to EPYC. I don't know if the slowdowns will warrant that though. Remains to be seen.
As for general effects, cloud service providers may need to start allocating more resources for each zone they service. If customer cloud apps start getting really heavy on CPU usage, the customers are going to start provisioning beefier machines which will lead to resource availability problems.
The above means more money must be spent by cloud providers to get machines, and more money must be spent by cloud customers to use the machines. A net loss for everyone.
Zachary Jenkins
AMD, Ryzen, or Ryzan2 are not affected at all. This is an Intel problem.
Henry Garcia
>I'm too dumb to read The baseline is that the actual vulnerability part does not affect AMD. We don't really know how it affects ARM because "muh secret phone computing club. No peeking." We just know meltdown works on some. >What will be done in the future Buy an AMD CPU with SME. Don't buy Intel's 25 years of garbage so you get 10 more frames in your sick shootmanz.
Lucas Rogers
"near zero" is the two words that indicate that it is in fact vulnerable but also puts to question what they mean by "near zero". as in, what is the scale they are measuring by when saying "near zero"? It is obvious they are talking to dumb investors so such a vague statement can satisfy the layman but anyone in the tech field would have reason to be curious especially if they have a security background.
Jose Collins
You didn't read. Try reading the actual white paper and CVE that describes exactly which vulnerabilities the AMD arch is susceptible to.
Grayson Cook
The sources stating vulnerabilities also affecting AMD do come from Google and the Linux forum which are 3rd party groups who are concerned more about security than petty fanboying. So it is worth a look regardless of AMD's statements. companies fudge the truth regardless of who's side you are on.
Aiden Ward
perhaps I overlooked it when digging. where did you get the information I am missing?
Easton Barnes
LOL is this some /biz/ faggot fishing for trading tips?
I cant imagine asking for an explanation without coming off as playing dumb so Ill just come out and say it. what the fuck are you talking about?
Lincoln Robinson
This is outright FUD. Why would you run untrusted code (inb4 do you vet all your dependencies) on your servers?
Cameron Peterson
Has no vulnerability on AMD x86_64 platform, vulnerability being ring0 protected pages visibile to ring3 processes and possibly using to further leverage rowhammer. AMD doesn't permit this ring0 page visibility under any circumstances. The mitigation for this vulnerability is to flush CPU cache every time time context switches privilege or PID, a VERY heavy hit up to 50% in some cases.
On AMD it IS possible for a user process to use timing attacks to view its own pages in cache, an example is using JS to view browser passwords in the same process which would normally be sandboxed. This is being fixed and has no performance penalty.
Anthony Bennett
...
Tyler Garcia
with very little experience programming I read this as >if x86 vendor is not AMD >then say x86 cpu is not secure which i find strange as you state to assume all x86 cpus are insecure, which sounds like a contradiction. am I understanding this right? what point are you making here?
Cameron Reyes
The Linux kernal doesn't apply any performance nerfing workarounds if the CPU arch is AMD64, because it doesn't affect AMD. Intel are the idiots who supplied the workaround which applied to every x86 arch, AMD supplied a patch to disable the workaround on AMD64 CPU as it doesn't have the flaw.
Angel Baker
RISC-V being fully verified and open source is one option.
Adam Myers
...
Samuel Smith
The only major professional concern I have at the moment is for the real-world performance impact on databases and Java in RedHat environments. My customers love to run callmanager pinned at full load and if we see even a 5% slip I expect a shitload of call centers will be rolling back the patch for this.
Julian Peterson
can you provide the implementation for that js hack? just curious
Logan Peterson
that's just a letter from linus bitching about Intel's priorities. I am talking security not public relations.
Jose Kelly
OP here script kiddie asking for gibs or actual security concern?
Kayden Howard
window.alert("URAFAGET");
Juan Green
Go and research it. FYI on INTEL the same approach can be used to access Kernel memory and also hypervisor access to other running VMs. Holy shit did Intel fuck up.
Elijah Parker
OP here okay so AMD so far is without a doubt confirmed safe from this and thanks to those who pointed that out without fanboy shitposting. here are links I dug up lkml.org/lkml/2017/12/27/2
Anyone watching over corporate/federal reaction to the recent news?
Aaron Miller
Yeah. Intel has some paid shills on the financial side of MSNBC and CBS, like how Lehman did in 2007, so shill for Intel's stock.
Xavier Evans
This whole thing consists of at least three different exploits. AMD is safe from one of them.
Isaac Howard
Yes, safe from the serious one which allows access to kernel and hypervisor memory. At worst the AMD exploit allows a process to see its own memory, which really only matters for web browsers and even then only within the same process; web browsers now run multiple processes.
Mason King
No you're not. That's a patch that fixes the earlier patch that assumed both amd and intel cpus were insecure. It's how git works.
Aaron Mitchell
And one of the others is already patched and the other exploit probably doesn't work on AMD
Bentley Martin
i read up on it more after that post. I understand
Jason Rivera
correct, the CVE does also complain of a timed JS attack vulnerability targetting the cache dumping that the processor does regularly.
Nathaniel Richardson
The CVE is dated as of beginning of January so I doubt it was already patched.
