The Meltdown and Spectre attacks were a wake-up call for processor manufacturers. They exposed the fact that processors are typically shipped with latent vulnerabilities. In some of the attack scenarios, the blame rests on a hardware design oversight (Meltdown), or on the side-effects of speculation (Spectre Variant 2), or on code that leaks information through side channels (Spectre Variant 1).
I expect that these specific attacks can and will be addressed in the coming years with hardware features that fix the design oversight or close certain side channels. Moving forward, manufacturers will likely be more paranoid about other potential side channels and the side-effects of performance optimizations.
The field experienced a very similar upheaval about three decades ago. We did discover that speculation had a very negative side effect -- its impact on consistency models. In fact, the fence instructions that came to our rescue in the 1990s are being used in some of the software patches for Spectre. These fence instructions essentially "disable" speculation when it's harmful.
As we teach speculation in architecture classes, it is important to point out these negative side-effects. Thanks to the attention received by Meltdown and Spectre, students in my classes were already very curious. I'm posting two of my screencasts here that may be useful to others that want to discuss these attacks in their undergraduate and graduate classes: Meltdown and Spectre.
