The Market Ticker
Rss Icon RSS available
You are not signed on; if you are a visitor please register for a free account!
The Market Ticker Single Post Display (Show in context)
User: Not logged on
Top Login FAQ Register Clear Cookie
User Info It's Operating As Designed (ROFL!); entered at 2018-01-04 01:14:37
Invis
Posts: 3
Registered: 2018-01-02
This all comes from here: https://meltdownattack.com/

(All exploits must have catchy names now, so we have Meltdown and Spectre).

Meltdown is essentially an Intel-only problem, and caused by such a basic design error that Intel should be made to replace affected CPUs no matter how old. This one is unforgivable and I'd love nothing more than to see Intel hang for it. They took a shortcut to gain some performance and, metaphorically, should be kicked in the balls repeatedly until they swear on pain of castration not only not to do it again, but show how they're not doing it. On the plus side, it's unlikely this can be exploited via JavaScript, so in the real world it's probably not all that serious for desktop users, but for a lot of "the cloud" it's catastrophic:

"Meltdown allows an unprivileged process to read data mapped in the kernel address space, including the entire physical memory on Linux and OS X, and a large fraction of the physical memory on Windows. This may include physical memory of other processes, the kernel, and in case of kernel-sharing sandbox solutions (e.g., Docker, LXC) or Xen in paravirtualization mode, memory of the kernel (or hypervisor), and other co-located instances"

Spectre is quite esoteric, probably impossible to work around in software, and the paper has a JavaScript PoC. Of the two it's probably the more serious for desktop users, and as I understand it, not an issue for "the cloud". I'm annoyed, but not surprised, by Spectre; the chip designers should know better, but given that micros were never thought of as real computers they likely never considered hostile code targeting the CPU itself.

Basically, both of these are cache poisoning attacks combined with an optimisation that should be transparent but isn't quite.

The /correct/ solution is for the silicon to return the /entire/ CPU to the state it was in before whatever speculative action took place, i.e. as if the optimisation had never happened, but whether that's at all practical I'll leave for someone with actual hardware knowledge.
2018-01-04 01:14:37