> but your professor assures you that implementors have been very careful to ensure any partial execution is properly flushed and rolled back.
And, at the time, your professor was correct, to the extent of what he/she defined as "any partial execution".
But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and the flags register). Their definition ignored the cache, because at the time the cache was considered simply a transparent optimization system that did not effect the values of contents of the CPU architectural state.
And in a way, that definition is still valid, even after the knowledge of these exploits. The CPU architectural state (registers/flags), even after executing exploit code, is exactly what it would have been had sequential execution happened. The exploit takes advantage of the fact that you can arrange the right set of code to run just the right way to leave a different state in the _cache_ (i.e., that thing believed to have been merely a transparent optimization).
It turns out now that the belief in the cache being transparent and only providing optimizations was the flaw in the belief system at the time.