111–120 of 205 posts
Would this entire Meltdown/Spectre thing count as the biggest mess-up of computing history? When yesterday the PoC repo was posted here, the spy.mp4 demo video gave me some chills. And now I can't update my OS before making an installation USB because Canonical can't just follow Linus' releases. Thanks.
I think that title is currently held (deserved or not) by null pointers. Tbh it’s not the most meaningful of statements, but it’s food for thought.
Earlier quoted context omitted.
Depends on the recall, the GM ignition recall was done on an independent appt basis. (besides you should not be taking your car to the dealer if you value your wallet)
You need a new dealer...most have greatly improved customer service experiences these days, and many independents are no panaceas...
Earlier quoted context omitted.
>Would this entire Meltdown/Spectre thing count as the biggest mess-up of computing history? When yesterday the PoC repo was posted here, the spy.mp4 demo video gave me some chills. It must be up there amongst the greats, probably with the "halt and catch fire" op code. Normally they just patch this stuff with microcode and never really tell anybody, this time that won't work. I'm not entirely convinced it was a mist…
I think it's absolutely unreasonable to imply that this was intentional. Besides the massive amount of complexity these systems have, there are plenty of "legitimate" places to hide backdoors, instead of in a performance architecture decision. Keep in mind that whatever "evil agencies" would have asked for this would most likely find themselves vulnerable, and nobody would sign off on. I do agree, however, the "secur…
it's the fault of Intel, why don't they recall all the CPU? just like vehicle company
The later is pretty analogous to issuing firmware and OS patches to mitigate the flaw.
Earlier quoted context omitted.
I think it's absolutely unreasonable to imply that this was intentional. Besides the massive amount of complexity these systems have, there are plenty of "legitimate" places to hide backdoors, instead of in a performance architecture decision. Keep in mind that whatever "evil agencies" would have asked for this would most likely find themselves vulnerable, and nobody would sign off on. I do agree, however, the "secur…
Well, I read somewhere the other day that this form of error/attack was conceived of in the academic literature back in 1992. I won’t believe it’s intentional without evidence in that direction, but this is conceivably the kind of obscure/complex attack you’d expect of a state actor.
It just keeps popping up, someone finally thought to weaponize it.
Earlier quoted context omitted.
I think it's absolutely unreasonable to imply that this was intentional. Besides the massive amount of complexity these systems have, there are plenty of "legitimate" places to hide backdoors, instead of in a performance architecture decision. Keep in mind that whatever "evil agencies" would have asked for this would most likely find themselves vulnerable, and nobody would sign off on. I do agree, however, the "secur…
The Intel Management Engine is a backdoor. Speed variations in speculative execution are an inherent property of the technology. Until recently, few people thought this was exploitable, and it took a lot of work to figure out how to exploit this.
Earlier quoted context omitted.
Are you suggesting that we recall the great bulk of modern CPU's? Like, literally gut everyone's computers, including those in data centers and running critical infrastructure, until replacements are eventually manufactured? Or did you mean something else?
I'd think it'd be reasonable to get a refund in some manner, provided you could provide proof-of-purchase for the CPU in question. I wouldn't expect them to replace any CPU, unless it was manufactured recently and still being manufactured. But a refund in some capacity? That's reasonable, I think. In the meantime, we would have to settle for the software fixes.
Earlier quoted context omitted.
A null pointer doesn't hold a reference, though.
It does if you have something at 0x0. Or, to put it another way, I have no clue to what you're referring--what do references have to do with "The Billion Dollar Mistake"[0]? [0]: https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra... EDIT: my apologies, that joke was actually pretty good.
Earlier quoted context omitted.
Boxed Intel processors carry a 3 year warranty. It certainly seems reasonable for everyone who bought a CPU within the last 3 years to expect a warranty replacement with the manufacturer defect fixed. In the EU virtually every product comes with a 2 year warranty. So every CPU sold in the EU in the last two years should be replaced for free by Intel, even through OEMs. I wonder what potential class action lawsuits In…
Any sufficiently complex CPU surely contains some number of defects, perhaps even serious security defects, just as any sufficiently complex piece of software contains bugs and security holes. I wouldn't be surprised if someone tries to sue Intel over this, or even if they win, but this is way outside the scope of what a warranty would traditionally cover, which in the case of a CPU would be hardware failure. If a wa…
This arch/x86/events/intel/ds.c fix is unlikely to have rendered too many things unbootable. I missed ds.c entirely when doing the original implementation. I can't fault the nice folks at Canonical for mis-merging a tiny hunk like this. It really only affects pretty specific hardware anyway.
What hardware does it effect?