INTEL OUT GET SPECTRE MELTDOWN CHIP FULL
It really is a rather simple (and fundamental) issue, there has been a grey cloud hanging over speculative execution since it was conceived (imagine the horrors it could wreak on memory-mapped I/O), but now that engineering curio has become a Problem I can't really see a way out other than locking out all forms of timing from untrusted code, including the ability to run raw code at full speed. I had modelled it on my understanding of Meltdown, but my test is more like Spectre because I'm abusing the branch predictor (incompetently).Ĭompare that to the statement in the Meltdown paper that they didn't get it working on AMD simply because it didn't - I'm not calling them incompetent but if they don't know why it didn't work and think it might work, then that's the last type of good news wanted by AMD (or ARM). Couldn't confirm speculative accesses on the C2D either (see my post above) but I think I'm just doing it wrong. I just tried on a C2D which didn't like that, 'prefixing' rdtsc with cpuid worked. Time to disembark from our pleasure cruise on denial. Still waiting for the running, screaming and hair on fire. Every everything is darn near wide open and remotely exploitable.
INTEL OUT GET SPECTRE MELTDOWN CHIP PROFESSIONAL
Perhaps it becomes harder to see with professional level training since professionals "know" even better than anyone that security disaster this bad "can't" happen. It certainly will I am nobody and if I'm getting it this bad then I can only imagine that everyone is or will. It's real, it's far worse than the most paranoid security scenarios ever imagined, and if you aren't under constant attack then you either don't realize you are being attacked, or your turn hasn't come yet. Many people who should be able to see and understand this stuff better than me still speak as if this is overblown. Not sure if I get attacked more than the average person (it seems to me I should be a boring target to either criminal or state attackers) or if there is widespread (psychological) denial. Every Intel and AMD processor I have is attacked remotely almost every day. And it is very easily exploited remotely.
Several AMD FX and at least one APU are affected. Additionally, because of the reference to "recent program behavior" in Intel's optimization manual, a bunch of conditional branches that are always taken were inserted in front of the indirect call. Before each indirect call, the function pointer stored in memory was flushed out to main memory using CLFLUSH to widen the speculation time window. Both indirect calls were performed through the same callsite. The injecting process performed indirect calls to a function that accesses a (per-process) test variable the measuring process performed indirect calls to a function that tests, based on timing, whether the per-process test variable is cached, and then evicts it using CLFLUSH. Both instances were executed with ASLR disabled and had the same code at the same addresses. Based on the assumption that branch predictor state is shared between hyperthreads, we wrote a program of which two instances are each pinned to one of the two logical processors running on a specific physical core, where one instance attempts to perform branch injections while the other measures how often branch injections are successful.
0 kommentar(er)
