[ 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 ]
>> No.67146043
File: 159 KB, 669x780, 1503135671196.jpg [View same] [iqdb] [saucenao] [google] [report]

>Understanding L1 Terminal Fault

>Red Hat

>> No.67146079
File: 123 KB, 638x599, 0000000002.jpg [View same] [iqdb] [saucenao] [google] [report]

Again, going to go AMD now.

>> No.67146936

>another hardware exploit fully compatible on intel server hardware
>ayymd hardware doesn't even support it
hahaha amd finished and bankrupt

>t. ruski harker

>> No.67146998

Their UI designer needs to fired.

>> No.67147020

>turns out building in Mossad backdoors also leaves you vulnerable for other attackers.

Who could have predicted this?

>> No.67147067 [DELETED] 
File: 185 KB, 1200x800, rabbi_harry_wanton_01.jpg [View same] [iqdb] [saucenao] [google] [report]

Delete this antisemitic post!

>> No.67147084
File: 614 KB, 992x1043, 1532984775087.png [View same] [iqdb] [saucenao] [google] [report]


>> No.67147108

>you actually need to fully disable hyper-threading to not be vulnerable to L1TF lvl 3 on your server
There goes the stock price again.

>> No.67147127
File: 8 KB, 249x200, 1381353060269.jpg [View same] [iqdb] [saucenao] [google] [report]

y... yeah, what the fuck?

>> No.67147347

No one cares AYYMD cucks. Even with all the exploits people rather use intel CPUs.

>> No.67147401 [DELETED] 

See, this is how every goyim should behave in front of a Jew, servile and docile.

>> No.67147629

>vulnerabilities don't matter!

>> No.67148502

Everytime this happens, the web is totally full of """executive summaries""" of these vulnerabilities and it's totally impossible to find actual technical details. Does anyone know what it's actually about?

>> No.67148662

Actually, I take that back. The RedHat explanation was actually technical enough to describe what's actually going on. Thanks for linking to it, senpai!

>> No.67148668

Literally who cares

>> No.67148769

Anyone running untrusted VMs would care very much.

>> No.67148779

I'll start with the logo.

>> No.67148780

>you actually need to fully disable hyper-threading to not be vulnerable to L1TF lvl 3 on your server
I don't think that's the case. Hypervisors/kernels just need to ensure that sibling threads aren't used to run VMs/processes that don't trust each other. Which quite arguably they should be doing anyway.

>> No.67148793

given it's yet another, intel specific exploit that requires disabling SMT and flushing L1 cache periodically or going back to trapping vm paging operations, anyone who depends on VMs

>> No.67148809

This parade of exploits is going to permanently assfuck Intel out of the hypervisor market sooner or later. I can't wait.

>> No.67148853 [DELETED] 
File: 112 KB, 691x771, 1525554923397.jpg [View same] [iqdb] [saucenao] [google] [report]



>> No.67148859

My machine works fine and my virtual machines work fine. It's fucking nothing.

>> No.67148865 [DELETED] 

t. Pajeet Goldstein

>> No.67148903

that's not the point idiot. this is literally a meltdown tier exploit that lets you fucking read memory in l1 cache because the speculative executor is too fucking lazy to fucking read one stupid ass bit on a page

>> No.67148953

But meltdown was never even used and even people who didn't update with any of the patches for it are fine.

>> No.67149042

"Intel always blah blah" published 90 days after no response from the careless money lovers!

>> No.67149085 [DELETED] 
File: 54 KB, 679x758, 1527629778452.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.67149189

Every competent intelligence agencies in the world are milking this for all it's worth, don't even kid yourself. They definitely have dedicated teams for these exploits.

100% guaranteed.

>> No.67149289 [DELETED] 

hello, AMDshill, how do you do?

>> No.67149301

Can you provide a source so it doesn't look like you're talking out of your ass?

>> No.67149336

CIA Vault 7 leaks confirmed they stockpile 0days and pressure companies to add backdoors. That's where all these "exploits" are coming from - targeted leaks to crush Intel.

>> No.67149406
File: 27 KB, 480x270, what-is-good.jpg [View same] [iqdb] [saucenao] [google] [report]

Can Intel chips even add 2+2 properly?

>> No.67149420

Not if you fuck with the speculative execution lol.

>> No.67149563

Frankly, if they haven't been exploiting it, they aren't doing their jobs.

>> No.67149655
File: 473 KB, 660x421, intel-2.png [View same] [iqdb] [saucenao] [google] [report]

>no 10 nm for more than another year, and even then it's worse than expected
>suddenly, vulnerabilities left and right, particularly critical for cloud virtualization, one of Intel's biggest cash cows
>amd returns to excellence with server cpus specifically aimed at cloud virtualization
It really is the perfect storm for Intel, isn't it?

>> No.67149682
File: 871 KB, 1400x730, Screenshot_20180814_225638.png [View same] [iqdb] [saucenao] [google] [report]

>the ride never ends

>> No.67150122

>5 to 15% in performance hit for servers running VMs (everyone)
>already had a 5 to 30% hit from spectre/meltdown

>> No.67150231

Compounding those two together, worst case you're looking at a 40.5% total performance hit from pre-Meltdown.
>Intel chips now half as fast
>Linux (and probably ESXi) twice as fast as Windows on TR2/EBYN due to NUMA and sheer core count
Wintel is literally finished.

>> No.67150312 [DELETED] 


>> No.67150339 [DELETED] 

intel lmao

>> No.67150433
File: 1.82 MB, 304x256, andrei.gif [View same] [iqdb] [saucenao] [google] [report]

> tfw hyperthreading axed from i7 line finally starts making sense

>> No.67150443

the people who knew/know about spectre and still buy/bought current intel are absolute retards

>> No.67150455

Fuck's sake!

>> No.67150470

>Side-channel attacks
>Speculative Execution
There's nothing new here, and it'll work on everything non-intel as well once you calibrate it.

>> No.67150551

>There's nothing new here, and it'll work on everything non-intel as well once you calibrate it.

most of these sidechannels are due to a pervasive design philosophy Intel maintained of aggressively following speculation and waiting until the last possible moment to do validation checks. other chip makers (but we'll just assume we're discussing x86 and thus only AMD here) have not gotten hit nearly as badly, and it has little to do with the attacks not be "calibrated" to them yet.

>> No.67150587

AMD engineers explicitly said "we are not vulnerable to this" when submitting code for a Meltdown patch to the Linux kernel, and suggested defining a CPU_INSECURE flag if the chip was Intel at all. In retrospect they were right.

>> No.67150682

As opposed to buying amd which is still also affected by spectre?
The only hardware methods to prevent side-channel memory timing attacks is to insert enable buffers at the caches and/or TLB that effectively temporarily disables a memory region that was loaded in from a execution violation, or to insert a tapered semi-random delay for memory access after an execution violation.

>most of these sidechannels are due to a pervasive design philosophy Intel maintained of aggressively following speculation and waiting until the last possible moment to do validation checks.
No. Most of these side channel attacks have nothing to do with that and will work on a majority of chip maker's cards. A small minority of the side channel attacks make use of Intel specific technologies or features; of course those won't affect others because it's literally tailor-made for the architecture. Any speculative execution or memory-sharing feature on other boards will also have their own attacks specific to that technology. The reason you don't "see" as many of those is because you have to spend your time targeting and testing that specific architectural feature and less people are using non-intel as a baseline.

>last possible moment to do validation checks
You have absolutely no idea how the fetch-decode-execute cycle works, do you? This is entirely the fault of the OS, not the hardware.

>> No.67150713
File: 1.25 MB, 1845x1923, intel.jpg [View same] [iqdb] [saucenao] [google] [report]

>all these lies and damage control
Isn't it pretty late in Tel Aviv?

>> No.67150741

So basically all the intended NSA & Israel backdoors are getting exposed by some vigilante?

>> No.67150747

The absolute state of x86. When will you give up on this shit?

>> No.67150759

Daily reminder that hating popular things doesn't make you an interesting person.

>> No.67150779
File: 249 KB, 800x495, Intel Israel 1976.jpg [View same] [iqdb] [saucenao] [google] [report]

>turns out building in Mossad backdoors also leaves you vulnerable for other attackers.

>> No.67150813

Clearly the only reason to hate x86 is popularity, even if the most popular processors are ARM.

>> No.67150819

If you're not an ignorant twat, you're in denial.

>Damage control
I'm not claiming that Intel is safe. I'm pointing out that everyone gets fucked by these. I cannot fathom how people ignored Spectre and tunnel visioned on Meltdown when the public found out about all these vulnerabilities. You think amd-specific performance enhancement architectures related to speculative execution and memory management are safe? You think any of this is new? This shit has been possible for years. Anyone in the same room as your computer could use the mic on their fucking cellphone to break any (most?) encryption happening on your computer in real time. If you don't have a faraday cage and a cardboard sound muffler on your laptop it's easily more vulnerable than the difference between having an intel chip and an amd chip would be.

>> No.67150898

To continue >You think any of this is new? This shit has been possible for years.
Have some papers and sources to read up on.
https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf >Cross-VM Side Channels and Their Use to Extract Private Keys
https://www.tau.ac.il/~tromer/acoustic/ https://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf >RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis
The Program Counter Security Model: Automatic Detection and Removal of Control-Flow Side Channel Attacks - USENIX
Defending against side-channel attacks - Gilbert Goodwill, Cryptography Research, Inc
Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems - Paul C. Kocher

If you want to be paranoid about Intel being unsafe due to side channel attacks, have fun with this instead: Lookup "hardware trojans" and then worry about if Intel, AMD, Nvidia, or even just any of the manufacturers who actually fabricated the chips have sneaked some in.

>> No.67150939

so does your english teacher

>> No.67153304

is core 2 duo, too?

>> No.67153715

What is Intel's next realistic step?

>> No.67153769

Crashing this industry, WITH NO SECURITY

>> No.67154366

Same goes for TLBleed. Even if you are magically not affected by L1TF V3, you will STILL be affected by TLBleed.

>> No.67154375

Bring back Itanium

>> No.67154747

It's a feature!

>> No.67154774

Release chips with all of the affected components disabled as a stopgap solution until like ~2020 when they release chips with the proper fixes implemented. It's gonna be a rocky couple of years for Intel.

>> No.67156222


Name (leave empty)
Comment (leave empty)
Password [?]Password used for file deletion.