Meltdown Proof-of-Concept

Post by loeg » Wed, Jan 10, 2018, 7:36 AM UTC

Xylakant wrote: post #46

HugoDaniel wrote: post #37

Earlier quoted context omitted.

Except if you are into *BSD. In that case you might want to label it "selective disclosure" instead of "responsible disclosure".

Well, since some of the BSD folks publicly stated that they’d ignore any embargo, that seems like a pretty predictable consequence. And in this case I understand that it took a while to develop workable mitigations. Immediate disclosure might have caused great harm.

Post by JdeBP » Wed, Jan 10, 2018, 7:45 AM UTC

Terr_ wrote: post #100

white-flame wrote: post #76

Earlier quoted context omitted.

No, creating a block of machine code bytes to execute would be a privileged operation. All code would run through a privileged CPU-specific compiler first, and there'd be no way to run raw machine code bytes otherwise. If there are bugs that can be exposed through various machine code patterns, the compiler can centralize the restrictions of what may be executed, enforce runtime checks, or prevent certain instruction…

> no way to run raw machine code bytes otherwise [...] restrictions of what may be executed, enforce runtime checks, or prevent certain instructions from being used at all [...] everything optimized for your environment better, allow much better compatibility across systems and prevent entire classes of privilege escalation issues. So... basically re-inventing Java? :) "Raw machine code bytes" aren't distributed but…

Post by ckastner » Wed, Jan 10, 2018, 8:36 AM UTC

warkdarrior wrote: post #121

krylon wrote: post #79

Earlier quoted context omitted.

> by the way, that PoC was intense. Makes you wonder if the NSA knew about it all along :) Colin Percival found a very similar issue with Intel's implementation of SMT on the Pentium 4 in 2005: http://www.daemonology.net/papers/htt.pdf So the general idea of using timing attacks against the cache to leak memory has been known for at least that long. In 2016, two researchers from the University of Graz gave a talk at…

Cache timing attacks have been known for a while, for example across VMs in 2009: https://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf

Post by arcticbull » Wed, Jan 10, 2018, 9:15 AM UTC

londons_explore wrote: post #112

gpderetta wrote: post #101

Earlier quoted context omitted.

Main memory access take an order of hundred cycles. D1 cache hit access usually take usually 3-4 cycles. Microarchitecture designers will take heroic efforts to even shave a single cycle here. Adding an overhead of even a couple of cycles would be a huge deal. Having said that, AMD CPUs are the existence proof that you can be immune to meltdown with no significant overhead. Spectre is a completely different issue tho…

AMD CPUs have pretty poor single threaded performance. Perhaps that because they haven't taken the speed short-cuts that Intel took...?

Post by mehrdadn » Wed, Jan 10, 2018, 9:18 AM UTC

tptacek wrote: post #146

_wmd wrote: post #145

Earlier quoted context omitted.

Perhaps I've been living under a rock for the past 30 years, but transient instructions are a new idea for me

What's the "old" term for speculated instructions that aren't retired?