Notes from the Intelpocalypse

Posted Jan 5, 2018 16:25 UTC (Fri) by MarcB (subscriber, #101804)
In reply to: Notes from the Intelpocalypse by samiam95124
Parent article: Notes from the Intelpocalypse

What do you mean?

My understanding of Meltdown is that it uses the limited speculative execution caused by classic pipelining+out-of-order execution (it does not use the advanced speculative execution that is used by Spectre). Or does it just use the reordering of stages, i.e. "read" before "check"?

It boldly accesses memory it is not allowed to access and then "defuses" the exception by forking beforehand and sacrificing the child process. Or it avoids exceptions by using TSX and rolling back. It then checks if a given address was loaded into cache or not by the forbidden access.

And apparently this does not work on AMD - and AMD claimed to never make speculative accesses to forbidden addresses - i.e. they must be checking earlier or never reorder "read" before "check".

However, I do not see, how AMD could do this with TSX; there allowing this forbidden access seems to be part of the spec. Or does Ryzen not have TSX?

Notes from the Intelpocalypse

Posted Jan 5, 2018 17:34 UTC (Fri) by foom (subscriber, #14868) [Link]

TSX isn't supposed to allow you to access memory you don't have permission to access, it just triggers a different response if you try – instead of a sigsegv, you get a transaction abort.

(Also, no, AMD doesn't implement it)

Notes from the Intelpocalypse

Posted Jan 6, 2018 14:58 UTC (Sat) by nix (subscriber, #2304) [Link]

It boldly accesses memory it is not allowed to access and then "defuses" the exception by forking beforehand and sacrificing the child process. Or it avoids exceptions by using TSX and rolling back. It then checks if a given address was loaded into cache or not by the forbidden access.

Nope. It boldly accesses memory and then uses the value read from that memory to read one of a variety of bits of memory it shares with the attacker, but it does all of that *behind a check which will fail*, so the reads are only ever done speculatively, and no exception is raised. Unfortunately the cache-loading done by that read still happens, and the hot cache is easily detectable by having the attacker time its own reads of the possible locations. (With more than two locations, you can exfiltrate more than one bit at once, possibly much more.)

Needless to say, if you have a way to exfiltrate the data other than a shared memory region, you can use it: the basic attack (relying on side-effects of speculations bound to fail) is the same.