INTURD

It's speculated that it works on Zen. It's not confirmed by anyone yet. You would know by now if it worked on Zen.

>"However, they suggested that all CPUs that use a Simultaneous Multithreading (SMT) architecture are impacted."

Google said the same thing with Meltdown and they didn't even bother testing on Ryzen/Epyc processors. It turned out that MELTDOWN = INTEL ONLY

why are security researchers doing this? Are they paid by Intel to spread fear against AMD products? Why aren't they testing on an AMD product before publishing? WOuldn't that get them more exposure if they were the first people to hack Ryzen/Epyc? Oh wait, they couldn't get it to work on AMD products so they pulled the good ol' "lying by omission" to lick Intel's arse

I don't buy that they didn't have the "resource" or "time" to test on at least one fucking AMD procuct

Yep. Of course they tested on at least one fucking Zen product, but couldn't get it to work. Just look at the disclosure timeline (HINT: AMD nowehere to be found in the list of companies that has been disclosed to)

## Disclosure timeline

01 Oct 2018: Notified Intel Security
26 Oct 2018: Notified openssl-security
26 Oct 2018: Notified CERT-FI
26 Oct 2018: Notified oss-security distros list
01 Nov 2018: Embargo expired

just imagine, right now some jew is stressfully trying to make it werk

>"Researchers suspect AMD processors are also impacted."

Would've been great if they tested their exploit on some AMD processors then, why didn't they if they have been working on it for months? really makes u think...

Google said same thing when they discovered Meltdown and said that AMD was probably affected aswell (HINT: AMD WERE NOT AFFECTED)

> (((Researchers)))

Yep, this is my understanding too. They don't "suspect" shit. If they did, they would've tested it and informed AMD one month beforehand, like they did with Intel, and like everyone in the business does. You don't just release an exploit like this and say "hey, maybe it affects this one other vendor too!!". They did test it and couldn't get it to work on AMD, for fucking sure.

>It's speculated
You've meant to say "ONLY speculated".

>It's not confirmed by anyone yet
It's pretty much guaranteed to work on Zen and POWER9 too. Again, the problem is fundamental to resource contention in SMT and that's a problem with SMT as a concept. If you eliminate all resource contention between two threads then you practically have a new core anyway and it's no longer SMT.

>You would know by now if it worked on Zen.
The PoC was released less than 24 hours ago, so no, that's not the case.

>1. Unconfirmed for Zen.
>2. Only SPECULATED for Zen.
See above. The fundamental problem that is exploited also exists on POWER9 and Zen, and any other SMT implementation.

You cannot eliminate resource all execution unit contention between two threads and still call it SMT. You then have two real cores, not a single core with SMT.

Does a PoC exist for Zen? No, but it should be portable to Zen with some effort.

>Google said the same thing with Meltdown and they didn't even bother testing on Ryzen/Epyc processors. It turned out that MELTDOWN = INTEL ONLY
Google never said the same thing about Meltdown. They said the same thing about Spectre, because Spectre is also a fundamental security problem with speculative execution. Guess what? AMD processors are very much vulnerable to Spectre v1.

Meltdown is a specific problem in Intel processors where the MMU only flags page faults when the processor attempts to retire the instruction, after the speculative load has been made. AMD's MMU flags page faults *before* the load is carried out, which is why AMD was never affected by Meltdown.

>why are security researchers doing this? Are they paid by Intel to spread fear against AMD products?
They are saying it because they're correct. It's a problem that is fundamental in the same way that Spectre v1 is fundamental to speculative execution. SMT is inherently dangerous and insecure.

>It's pretty much guaranteed to work on Zen

"Source: my buttmad kvetching ass"

>SMT is inherently dangerous and insecure.
>It's pretty much guaranteed to work on Zen and POWER9 too.

50000000000000000000000 rupees ($0.00) has been deposited to your bank account.

/Intel Damage Control Team

>It's pretty much guaranteed to work on Zen and POWER9
>exists on POWER9 and Zen
Holy fuck you are one DESPERATE Inturd shiller, lol

You forgot to enter the tripcode and log, Ryan Shrout.

NOOOOOOOOO WE GOT TO COCKY INTELBROS!!

Attached: 1539084715869.jpg (748x900, 138K)

>We are cucky
Exactly. That you are, indeed.

shut up goy

U seem MA

>"Source: my buttmad kvetching ass"
I own two 1700X, so no.

I am not a shill, I just understand what the vulnerability is. What's being exploited is the concept of sharing execution units, which is the definition of SMT. Thus all SMT implementations should be vulnerable.

I own two Ryzen 1700X and as you can see I have disabled SMT myself, because the technology is fundamentally insecure. There is a reason that OpenBSD 6.4+ disables *all* SMT, including on Ryzen.

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 8
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 1
Model name: AMD Ryzen 7 1700X Eight-Core Processor
Stepping: 1
CPU MHz: 1971.755
CPU max MHz: 3400.0000
CPU min MHz: 2200.0000
BogoMIPS: 6786.72
Virtualization: AMD-V
L1d cache: 32K
L1i cache: 64K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

I'm not. As I've explained already, I can say that because the exploit is attacking the very concept of sharing execution units between threads, which is the very definition of SMT. If you do not share execution units between threads, then you don't have SMT.

I just understand what is actually being exploited and as such I can say with confidence that Zen, POWER9 and ANY other architecture with SMT (shared execution units between threads) is vulnerable.

See . I actually have two Ryzen 1700X and that's lscpu output of one of them.

>guaranteed to work on Zen
>exists on POWER9 and Zen
>I'm not a buttmad Inturd shill

Nice try, faggot. But you'll need to try way harder than just that, to convince anyone here you're not a very obvious cuck.

Which kernel parameter do you use to kill it? nosmt?

Also, holy shit, I need to take the Blade Runner test. Apparently I don't know what a fucking bus actually is.

just delid and delap it

Why do people buy CPUs that are fundamentally broken on a hardware level?

To support jewish people and diversity

Cause we have been lied to all along.

Disabled in UEFI.

>he has an Intel CPU

Attached: Laughing Anime Girls.png (960x1080, 1.37M)

1. Idiots.
2. Brainless sheep.
3. Brainless sheeple idiots.

What about those who buy them in the last few months?

3. Brainless sheeple idiots.

Ah. I modified the hell out of a pre-built from HP's business unit that doesn't have that option, bizarrely. Was the only way I could get tSME (or SME) without going server-grade.

>Look mom, I posted about microarchitecture again!

These fucks don't understand the difference between a fundamental issue with SMT and a Intel getting sloppy with their pipeline

Attached: 031617-Karlie-Kloss-LEAD.jpg (2000x2401, 661K)

>It's pretty much guaranteed to work on Zen and POWER9 too

Cool can you show us where that is the case?

Nice exploit test you have there.

|
|>
|
|
|

Attached: 1541178114675.jpg (2000x1743, 176K)

I see what you have done user. xD

>pngquant --nofs -s9
Any advice for IRL photos?

I can't stop shaving these enough.

** needs to be added, for "** - AMD's 1 hardware vulnerability was already patched via simple OS update (motherboard BIOS update is fine too, but it's NOT necessary)"

Attached: J 0808.png (440x1004, 3.37M)

Oh wait...

What sort of workload are you running on this computer, and what would you say the perceived impact has been since disabling SMT?

It is fairly frequent for me to compile and encode. The performance impact from disabling SMT for multithreaded workloads is up to ~25%, so it really isn't ideal.

Are these regular-use desktop machines? If so, would you be experiencing serious performance degradation or lockups while running your heavy tasks?

The only think that'c compiling here, is your clenched buttmad ass.

>Are these regular-use desktop machines?
Yes.

>If so, would you be experiencing serious performance degradation
As I said, sort of depends on the workload, but there should be a ~25% multithreaded performance hit in the worst case scenario.

>lockups while running your heavy tasks?
Not sure why I would have lockups or anything of the sort.

Doesn't look like I'm the one who's buttblasted :^)

sandy is too and they wont even fix bugs from cpus that old

ESAD

2600k still werks

imagemagic or gimp, jpeg or flif i guess
pngquant may work ok for some irl pngs but usually shoudn't because they have shades and richer colours
maybe use 100% quality jpg on your camera or something 'lossless' and then convert it to flif later, or use png and use one of those lossless png optimisers

Xeon Isn't Epyc
lmao

Attached: coal.jpg (1600x1274, 983K)

>As for the impact on AMD systems, the research team told ZDNet that they strongly suspect that AMD CPUs are also impacted.

AMD shills gonna shill

>pngquant --nofs -s9
So we should disable Floyd-Steinberg dithering and run at speed 9 instead of the default setting of 3? Why? There's a big difference between using some png as is and running it through pngquant with default options. Everyone should do that. But you're adding two options and creating slightly larger files as a result. Why would you do this?

Attached: 1541175161153-fs8.png (2000x1543, 27K)

cos i played around with it and found the minimal gain to be insignificant to the speed
the floyd thing made them either bigger or look worse iirc

might as well post this

.config/mimeapps.list
image/png=conv-png.desktop;

.local/share/applications/conv-png.desktop
[Desktop Entry]
Type=Application
Name=to indexed colours
#Exec=/usr/bin/sh conv-png.sh
Exec=pngquant --nofs -s9 -f -- %f
StartupNotify=false
#Terminal=true
NoDisplay=true
Icon=media-record

>It is a fundamental problem with SMT
Perhaps, perhaps not. Do not forget that Intel really did submit a general patch to the Linux Kernel which would have put Meltdown mitigation in place for ALL x86-64 CPUs including AMDs. AMD had to fight to get their CPUs, which really are unaffected, excluded.

>the difference between a fundamental issue with SMT and a Intel getting sloppy with their pipeline
Time will tell. I wouldn't rule out that this could be a problem with AMD CPUs and other CPUs just like some Spectre variants do work on AMD chips. But there is some indication it's Intel only because
>The PoC was released less than 24 hours ago, so no, that's not the case.
does not mean it was discovered 24 hours ago and Intel was notified a month ago.

If you look at the github:
>This exploit code should work out of the box on Skylake and Kaby Lake. For other SMT architectures, customizing the strategies and/or waiting times in spy is likely needed.
This essentially means that they believe it could work on other CPUs with SMT but they don't actually know if that's the case or how they would do it.

Thanks, that's really useful, here I was going to a terminal and typing pngquant file.png all the time because I didn't think to do that myself...

>jpg
you did that just to spite him didn't ya :^)

>the floyd thing made them either bigger or look worse iirc
i mean it might be better for some pics like picrelated but for screen caps it's irrelevant

Attached: ckok-fs8.png (304x191, 29K)

Is my Haswell i7-4770k vulnerable to this?

WTFh does Shin Migami Tensay have to do with intel you fucking nigger?

>Is my Haswell i7-4770k vulnerable
github.com/bbbrumley/portsmash
"This exploit code should work out of the box on Skylake and Kaby Lake. For other SMT architectures, customizing the strategies and/or waiting times in spy is likely needed."

There's no good answer beyond stating the fact that there's no exploit code or anything else showing that it is, in fact, vulnerable to this. That obviously doesn't mean it's not, and the same applies to all other CPUs.

You can be sure that people will try during the coming months now that this has become public knowledge. We'll know if other Intel and AMD and Power CPUs have this problem soon enough. You might as well assume it's safe for now.

ftfy

Attached: inlel-or8.png (1900x900, 19K)

>I actually have two Ryzen 1700X
yeah you posted this two times already, you seem a bit desperate

it's anti-semitic not to

> i don't know who's jewing who anymore .jpg

PortSmash confirmed on several Broadwell processors. Needs trivial adjustment in spy source.

A new one? Where?

Anything after Sandy, is a rehash of Sandy, meaning EVERY thing after Sandy is affected.

Here is one with the context user.

Attached: coal2.jpg (960x720, 116K)

man, what am i supposed to upgrade to with an oc'd 7600k for gaming? everyone keeps telling me intel, and amd doesn't seem to have any options that wouldn't be anything more than a "sidegrade."

>a-amd might have it too.
>n-not just us.

Attached: 1515221586890.png (682x792, 339K)

You don't. There is no upgrade path.

>after Sandy
Most of these vulnerabilities date all the way to P3 or P4(even if no-one bothers actually verifying them on systems that old).

>SMT is inherently dangerous and insecure.
Are you the same guy who said that all types of Cache are insecure because Intel Processors suffers from L1TF?

>
H0w different is this from TLBleed?

Having only 4c/4t means shitty minimum framerates in some games, so in that regard a 2600(x) or 8600k would be a significant upgrade, but unless you really feel like upgrading ASAP, you might as well wait for Zen 2 and see how it performs like. It ought to be pretty impressive improvement over Zen+ especially if AMD can actually push the boost clocks to something like 4.7 GHz.

> This essentially means that they believe it could work on other CPUs with SMT but they don't actually know if that's the case or how they would do it.

No. It means that it exploits the very basis on the way SMT works, so SMT should generally be affected. Ie. when doing SMT, resources are *always* in contention, and you can time shit from that contention, to reveal enough information about the other thread to crack it.

Now, I suppose AMD might not have "raw" SMT, they might have buggered around with the timings, for example, having known this very flaw. But that eats up precious silicon, and unless they knew it'd be an issue, they wouldn't do it. There's various other reasons that AMD might not be affected, but I think it's unlikely.

The basics of SMT doesn't really change much from chip to chip -- they all work largely the same, so are likely all to be affected. Just like spectre exploits general implementation speculative execution (and thus affects a wide variety of architectures).

>No. It means that it exploits the very basis on the way SMT works, so SMT should generally be affected.
In theory. But keep in mind that Intel's HT implementation is actually pretty different from IBM's and AMD's SMT.

I know about that one, but never saw the COAL board. Also, needs a photo from the other angle, IYKWIM.

>what am I supposed to upgrade to from a 7600K
Zen 2. Do the ONLY right thing.

>In theory. But keep in mind that Intel's HT implementation is actually pretty different from IBM's and AMD's SMT.
And unless they bugger the timing of threads during resource contentions, they're all equally vulnerable.

>And unless they bugger the timing of threads during resource contentions, they're all equally vulnerable.
That has yet to be demonstrated.

So delusional, this buttmad Inturd shiller is.

>X doesn't really change much from chip to chip -- they all work largely the same, so are likely all to be affected. Just like Y exploits general(ly) Z (and thus affects a wide variety of architectures).

That can generally be said to cache implementations as well

However only Intel is affected by L1TF/Foreshadow, partially due to them to using VIPT L1 data caches instead of PIPT L1 data caches like Ryzen did

You are concluding based on incomplete evidence, and also arguing along the lines of "You can't prove something doesn't exist, so it does"

>suddenly all Intel CPUs are being probed for backdoors just after AMD re-entered the CPU market
>all of them require the attacker being a ninja CIA man who will need to physically tamper your CPU or get within your network for it to truly work
>even with 20+ vulnerabilities there isn't a real world attack yet

Manufactured exploits to force competition? How come nobody mentioned these backdoors 5-10 years ago? Why only bring them up now when AMD returns to the CPU space?

|
|>
|
|
|

>suddenly
The research leading up to some of these exploits has lasted for a decade.

>within your network for it to truly work
Wow, that's like impossible. Especially when you're connected to the Internet. Must be some serious CIA man indeed.