|
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?
|
# ? Jan 4, 2018 00:06 |
|
|
# ? Apr 25, 2024 16:38 |
|
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.
|
# ? Jan 4, 2018 00:08 |
|
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
|
# ? Jan 4, 2018 00:10 |
|
the new amd cpus are really really good, so obviously they're called epyc
|
# ? Jan 4, 2018 00:12 |
|
ex dee el em ay oh
|
# ? Jan 4, 2018 00:12 |
|
it's not even their enthusiast stuff, it's the name of their server line? goddamn
|
# ? Jan 4, 2018 00:13 |
|
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
|
# ? Jan 4, 2018 00:14 |
|
is it exactly like 1999-2004, in that no one makes an amd mainboard that isn't complete dogshit garbage?
|
# ? Jan 4, 2018 00:18 |
|
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
|
# ? Jan 4, 2018 00:23 |
|
AMD processors are just too slow for the exploit to work
|
# ? Jan 4, 2018 00:28 |
|
https://twitter.com/nicoleperlroth/status/948684376249962496 read the whole tweet thread
|
# ? Jan 4, 2018 00:30 |
|
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 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
|
# ? Jan 4, 2018 00:31 |
|
Number19 posted:https://twitter.com/nicoleperlroth/status/948684376249962496 why do people do this
|
# ? Jan 4, 2018 00:31 |
|
YOSPOS: Cache Ruins Everything Around Me
|
# ? Jan 4, 2018 00:38 |
|
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
|
# ? Jan 4, 2018 00:40 |
|
Linguica posted:YOSPOS: Cache Ruins Everything Around Me
|
# ? Jan 4, 2018 00:47 |
|
jfc this is bad
|
# ? Jan 4, 2018 00:51 |
|
Linguica posted:YOSPOS: Cache Ruins Everything Around Me
|
# ? Jan 4, 2018 00:52 |
|
https://twitter.com/timgostony/status/948682862844248065
|
# ? Jan 4, 2018 00:52 |
|
wow. lol.
|
# ? Jan 4, 2018 01:03 |
|
Number19 posted:https://twitter.com/nicoleperlroth/status/948684376249962496 time-sharing systems were a mistake
|
# ? Jan 4, 2018 01:10 |
|
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
|
# ? Jan 4, 2018 01:13 |
|
Stymie posted:it's always nice to be karmically backed up in a boycott of a company by their own gross incompetence trump finally repeals moore's law but only for jews
|
# ? Jan 4, 2018 01:17 |
|
hey alexa what's 4,195,835 divided by 3,145,727code:
|
# ? Jan 4, 2018 01:19 |
|
vmware has their updates for this out now: https://www.vmware.com/security/advisories/VMSA-2018-0002.html
|
# ? Jan 4, 2018 01:26 |
|
Jabor posted:burn it all down. it's done. 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
|
# ? Jan 4, 2018 02:16 |
|
someone explain how this exploit works please.
|
# ? Jan 4, 2018 02:28 |
|
e: i'm dumb an intel guy is notquote: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. flakeloaf fucked around with this message at 02:42 on Jan 4, 2018 |
# ? Jan 4, 2018 02:38 |
|
from the whitepaperquote: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. 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 |
# ? Jan 4, 2018 02:41 |
|
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
|
# ? Jan 4, 2018 02:58 |
|
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"
|
# ? Jan 4, 2018 03:02 |
|
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.
|
# ? Jan 4, 2018 03:02 |
|
that was fast https://twitter.com/misc0110/status/948706387491786752
|
# ? Jan 4, 2018 03:04 |
|
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
|
# ? Jan 4, 2018 03:06 |
|
nice!
|
# ? Jan 4, 2018 03:08 |
|
|
# ? Jan 4, 2018 03:33 |
|
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? 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
|
# ? Jan 4, 2018 03:36 |
|
thread keeps deliverin
|
# ? Jan 4, 2018 03:38 |
|
jaysus
|
# ? Jan 4, 2018 03:53 |
|
|
# ? Apr 25, 2024 16:38 |
|
Number19 posted:https://twitter.com/nicoleperlroth/status/948684376249962496 lol so much for Moore’s law, holy poo poo guess software will just have to pick up the performance slack again
|
# ? Jan 4, 2018 04:08 |