Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
Deep Dish Fuckfest
Sep 6, 2006

Advanced
Computer Touching


Toilet Rascal

quote:

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them.

the security conscious power user is once more rewarded for choosing the superior option: the cyrix processor

also i've seen the word "epyc" thrown around regarding amd's new platform. this is possibly the stupidest name for anything ever, so i'm assuming this is the actual official name?

Adbot
ADBOT LOVES YOU

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
burn it all down. it's done.

so are we just going to stop speculative execution entirely? that seems like the only fix, unless you want to make it possible to hermetically rollback all the side effects of a misprediction. and even then you could probably race it on a different core and see the effects on shared cache levels before they get rolled back.

infernal machines
Oct 11, 2012

we monitor many frequencies. we listen always. came a voice, out of the babel of tongues, speaking to us. it played us a mighty dub.

Deep Dish Fuckfest posted:

also i've seen the word "epyc" thrown around regarding amd's new platform. this is possibly the stupidest name for anything ever, so i'm assuming this is the actual official name?

you tell me

Truga
May 4, 2014
Lipstick Apathy
the new amd cpus are really really good, so obviously they're called epyc

FAT32 SHAMER
Aug 16, 2012




ex dee el em ay oh

Deep Dish Fuckfest
Sep 6, 2006

Advanced
Computer Touching


Toilet Rascal

it's not even their enthusiast stuff, it's the name of their server line? goddamn

Truga
May 4, 2014
Lipstick Apathy
the desktop line is RYZEN and the worstation line is THREADRIPPER and the server line is EPYC.

they're all really good, welcome to 1999, we're about to enter the age of AMD

infernal machines
Oct 11, 2012

we monitor many frequencies. we listen always. came a voice, out of the babel of tongues, speaking to us. it played us a mighty dub.
is it exactly like 1999-2004, in that no one makes an amd mainboard that isn't complete dogshit garbage?

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh
interesting bit from the meltdown paper:

quote:

We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

sounds like arm and amd have the bug and they just haven't figured out how to leak any data yet, but it might be possible

Sent from my iPad
Jun 19, 2000

AMD processors are just too slow for the exploit to work

Number19
May 14, 2003

HOCKEY OWNS
FUCK YEAH


https://twitter.com/nicoleperlroth/status/948684376249962496

read the whole tweet thread

:stare:

Truga
May 4, 2014
Lipstick Apathy

infernal machines posted:

is it exactly like 1999-2004, in that no one makes an amd mainboard that isn't complete dogshit garbage?

fortunately, that part got fixed by amd by just including the chipset on the SoC, the amd mobos are basically power delivery and various traces to external devices :v:

also, amd is being very mad about being lumped in with meltdown lol
https://www.cnbc.com/amp/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html?__twitter_impression=true
https://twitter.com/ryanshrout/status/948683677244018689

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh

why do people do this

Linguica
Jul 13, 2000
You're already dead

YOSPOS: Cache Ruins Everything Around Me

Sagebrush
Feb 26, 2012

Avenging Dentist posted:

why do people do this

Modern journalism dot aych tee em ell

I once got roped into reading a Twitter thread that turned out to be a 3000 word dissertation. Utterly loving owned

Crusader
Apr 11, 2002

Linguica posted:

YOSPOS: Cache Ruins Everything Around Me

The Management
Jan 2, 2010

sup, bitch?
jfc this is bad

AggressivelyStupid
Jan 9, 2012

Linguica posted:

YOSPOS: Cache Ruins Everything Around Me

Celexi
Nov 25, 2006

Slava Ukraini!
https://twitter.com/timgostony/status/948682862844248065

fart simpson
Jul 2, 2005

DEATH TO AMERICA
:xickos:


wow. lol.

ComradeCosmobot
Dec 4, 2004

USPOL July

time-sharing systems were a mistake

Stymie
Jan 9, 2001

by LITERALLY AN ADMIN
it's always nice to be karmically backed up in a boycott of a company by their own gross incompetence

i hope intel never recovers and is forced to return the land they stole in palestine

Truga
May 4, 2014
Lipstick Apathy

Stymie posted:

it's always nice to be karmically backed up in a boycott of a company by their own gross incompetence

i hope intel never recovers and is forced to return the land they stole in palestine

trump finally repeals moore's law

but only for jews

flakeloaf
Feb 26, 2003

Still better than android clock

hey alexa what's 4,195,835 divided by 3,145,727

code:
i don't know but your neighbour's credit card number is four five zero one six ei...

Number19
May 14, 2003

HOCKEY OWNS
FUCK YEAH


vmware has their updates for this out now: https://www.vmware.com/security/advisories/VMSA-2018-0002.html

JawnV6
Jul 4, 2004

So hot ...

Jabor posted:

burn it all down. it's done.

so are we just going to stop speculative execution entirely? that seems like the only fix, unless you want to make it possible to hermetically rollback all the side effects of a misprediction. and even then you could probably race it on a different core and see the effects on shared cache levels before they get rolled back.
i wanna go on my cache inclusion rant but idk if it'll even make sense

but yeah, it's possible to tag speculative <everything> and blast it out when the mispredict is known. for cache entries i think you can get by with 1 bit, for other things you'd need a colored tag

Stereotype
Apr 24, 2010

College Slice
someone explain how this exploit works please.

flakeloaf
Feb 26, 2003

Still better than android clock

e: i'm dumb an intel guy is not

quote:

The attack exploits speculative execution, and depends on a cache side attack as well. There isn't really a bug, as speculative execution is working as designed, which is to say it won't effect registers or memory (unless committed), but may effect the cache. So the attack causes the CPU to first take some sort of fault or trap, and this is followed in program order by some instructions that access privileged memory that the process otherwise wouldn't have access to. These instructions will never retire, because the trap will cause them to abort, but may execute speculatively. If they execute speculatively, despite being aborted, they may effect the cache. So then the attack would use a side channel attack to divine the contents of the cache, and voila, you have your privileged data. Except maybe not, it would depend on whether the instructions were actually speculatively executed, where the memory contents of those speculative instructions ended up by the time the abort happened, and then would depend on your ability to find them in the cache, which isn't guaranteed either.

So basically any hardware that supports speculative execution is vulnerable. Operating Systems can fix most of this, and there are lots of options for hardware fixes as well. But at present, the level of vulnerability is basically directly related to the depth of the out of order engine and the size of other structures. This really sucks, because this basically means that a faster a core is (independent of frequency) the more vulnerable it is. This paper says that they found all of Intel, AMD, and ARM to be vulnerable, but they couldn't get a working attack on AMD or ARM, likely because they have less sophisticated and shorter out of order engines (it sounds like ARM has another related issue though). So Intel is the most exposed, because they have the higher performance out of order engine.

The Spectre attack is much less generalized, but effects all CPU vendors equally. You're less at risk, because the attack has to target a specific process, but it's harder to fix as well.

flakeloaf fucked around with this message at 02:42 on Jan 4, 2018

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh
from the whitepaper

quote:

Meltdown combines the two building blocks discussed in Section 4. First, an attacker makes the CPU execute a transient instruction sequence which uses an inaccessible secret value stored somewhere in physical memory (cf. Section 4.1). The transient instruction sequence acts as the transmitter of a covert channel (cf. Section 4.2), ultimately leaking the secret value to the attacker.

Meltdown consists of 3 steps:

Step 1
The content of an attacker-chosen memory location, which is inaccessible to the attacker, is loaded into a register.

Step 2
A transient instruction accesses a cache line based on the secret content of the register.

Step 3
The attacker uses Flush+Reload to determine the accessed cache line and hence the secret stored at the chosen memory location.

By repeating these steps for different memory locations, the attacker can dump the kernel memory, including the entire physical memory.

a transient instruction is what they call code from a mispredicted branch that has visible side effects

Avenging Dentist fucked around with this message at 02:43 on Jan 4, 2018

Stereotype
Apr 24, 2010

College Slice
so the issue is that the cpu buffers memory blocks into the cache before determining if that memory block is privileged, then doesn’t immediately remove it before executing another instruction, which is allowed to access that cache to determine the stored value? then just repeat that bajillion times and you’ve got the whole memory?

so, since what the cpu does is literally built into the cop, the fix is to have the kernel order that cache address cleared if the cpu returns a privileged memory address error?

lol drat

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh

Stereotype posted:

so the issue is that the cpu buffers memory blocks into the cache before determining if that memory block is privileged, then doesn’t immediately remove it before executing another instruction, which is allowed to access that cache to determine the stored value? then just repeat that bajillion times and you’ve got the whole memory?

this is correct i think

quote:

so, since what the cpu does is literally built into the cop, the fix is to have the kernel order that cache address cleared if the cpu returns a privileged memory address error?

this is not (again, i think). kpti is a mitigation strategy to do aslr (in some way that's better than the old, vulnerable kaslr - don't ask me how because i have nfc), so all it's doing is saying "hey you can use meltdown to grab kernel memory but you won't know what you got because it's random"

The_Franz
Aug 8, 2003

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce

bunch of fixes for this were pulled into the 4.15 kernel including the amd exclusion patch. now only intel will suffer a performance penalty.

repiv
Aug 13, 2009

that was fast

https://twitter.com/misc0110/status/948706387491786752

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh

The_Franz posted:

bunch of fixes for this were pulled into the 4.15 kernel including the amd exclusion patch. now only intel will suffer a performance penalty.

the python sweetness post suggests that kpti would also be a strategy for mitigating rowhammer attacks so there may be some real value to this on any cpu; basically use it as an extra layer of protection to deal with a wide variety of hardware bugs

Toad King
Apr 23, 2008

Yeah, I'm the best

nice!

Crusader
Apr 11, 2002


tractor fanatic
Sep 9, 2005

Pillbug

Stereotype posted:

so the issue is that the cpu buffers memory blocks into the cache before determining if that memory block is privileged, then doesn’t immediately remove it before executing another instruction, which is allowed to access that cache to determine the stored value? then just repeat that bajillion times and you’ve got the whole memory?

so, since what the cpu does is literally built into the cop, the fix is to have the kernel order that cache address cleared if the cpu returns a privileged memory address error?

lol drat

i think you use the kernel value to index into your own memory. you can then tell what the kernel value was based on which part of your memory got cached

Best Bi Geek Squid
Mar 25, 2016
:discourse:

thread keeps deliverin

Captain Foo
May 11, 2004

we vibin'
we slidin'
we breathin'
we dyin'

jaysus

Adbot
ADBOT LOVES YOU

My Linux Rig
Mar 27, 2010
Probation
Can't post for 6 years!

lol so much for Moore’s law, holy poo poo

guess software will just have to pick up the performance slack again

  • Locked thread