Quantcast
[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr / vt ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Due to resource constraints, /g/ and /tg/ will no longer be archived or available. Other archivers continue to archive these boards.Become a Patron!

/g/ - Technology


View post   

[ Toggle deleted replies ]
File: 201 KB, 1200x803, vrouw-boardroom-41.jpg [View same] [iqdb] [saucenao] [google] [report]
64138511 No.64138511 [Reply] [Original] [archived.moe] [rbt]

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.

>> No.64138527

>>64138511
AMD doesn't just severley downplay the effects, they outright state that their CPUs have a "near zero risk" of exposure to the vulnerabilities.

>> No.64138547

>>64138511
>I want to have a more serious discussion
lmao too bad, POST ANIME AND INSTALL GENTOO.
>>>/reddit/

>> No.64138551

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

>> No.64138552

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

>> No.64138564

>>64138511
AMD, Ryzen, or Ryzan2 are not affected at all.
This is an Intel problem.

>> No.64138597

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

>> No.64138612

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

>> No.64138623

>>64138612
You didn't read. Try reading the actual white paper and CVE that describes exactly which vulnerabilities the AMD arch is susceptible to.

>> No.64138650

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

>> No.64138655

>>64138623
perhaps I overlooked it when digging. where did you get the information I am missing?

>> No.64138708

>>64138511
LOL is this some /biz/ faggot fishing for trading tips?

>> No.64138727
File: 583 KB, 865x1338, 9834214353.jpg [View same] [iqdb] [saucenao] [google] [report]
64138727

Friendly reminder that he warned us for years.

https://marc.info/?l=openbsd-misc&m=119318909016582

>> No.64138728
File: 95 KB, 500x407, shitposting-license-19226736.png [View same] [iqdb] [saucenao] [google] [report]
64138728

>>64138708
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?

>> No.64138748

This is outright FUD. Why would you run untrusted code (inb4 do you vet all your dependencies) on your servers?

>> No.64138782

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.

>> No.64138794
File: 47 KB, 649x280, committed.jpg [View same] [iqdb] [saucenao] [google] [report]
64138794

>>64138650

>> No.64138836

>>64138794
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?

>> No.64138884

>>64138836

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.

>> No.64138893

RISC-V being fully verified and open source is one option.

>> No.64138902
File: 65 KB, 726x781, intel btfo.png [View same] [iqdb] [saucenao] [google] [report]
64138902

>>64138836

>> No.64138916

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

>> No.64138921

>>64138782
can you provide the implementation for that js hack? just curious

>> No.64138957

>>64138902
that's just a letter from linus bitching about Intel's priorities. I am talking security not public relations.

>> No.64138990

>>64138921
OP here
script kiddie asking for gibs or actual security concern?

>> No.64139019

>>64138921

window.alert("URAFAGET");

>> No.64139328

>>64138921

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.

>> No.64139510
File: 6 KB, 239x250, 1424170850007s.jpg [View same] [iqdb] [saucenao] [google] [report]
64139510

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
https://lkml.org/lkml/2017/12/27/2

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/998707-initial-benchmarks-of-the-performance-impact-resulting-from-linux-s-x86-security-changes

https://www.cvedetails.com/vulnerability-list/vendor_id-7043/AMD.html

https://www.cvedetails.com/cve/CVE-2015-7724/
>basically a driver issue that can be fixed without hurting performance

also, some eye-candy for faggot fanboys to shitpost about intel later.
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

Anyone watching over corporate/federal reaction to the recent news?

>> No.64139557

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

>> No.64139940

>>64139510
This whole thing consists of at least three different exploits. AMD is safe from one of them.

>> No.64139978

>>64139940

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.

>> No.64140014

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

>> No.64140032

>>64139940
And one of the others is already patched and the other exploit probably doesn't work on AMD

>> No.64140436

>>64140014
i read up on it more after that post.
I understand

>> No.64140454

>>64139940
correct, the CVE does also complain of a timed JS attack vulnerability targetting the cache dumping that the processor does regularly.

>> No.64140464

>>64140032
The CVE is dated as of beginning of January so I doubt it was already patched.

>> No.64141039
File: 212 KB, 793x307, 1515030908828.png [View same] [iqdb] [saucenao] [google] [report]
64141039

Straight from the source (google)

>> No.64142496

>>64138511
fake news

>>
Name (leave empty)
Comment (leave empty)
Name
E-mail
Subject
Comment
Password [?]Password used for file deletion.
Captcha
Action