A year would be a fairly aggressive timeline. Ultimately SPECTRE et al are just exemplars of a class of exploit that I'm not sure anybody has seriously thought about how to deal with systematically. I've done the "daydream off for five minutes and try to solve the problem" a couple of times and I generally get to "let's design a new CPU from the ground up, using an entirely new set of formalisms"[1] pretty quickly, which is, ah, let's say, not a one-year effort to get it into customer hands. Timing attacks suck.
[1]: By this I mean that in general, our formal systems dump time as a consideration as quickly as they can. The systems designing the CPUs themselves don't, of course, because time is a big deal in making a modern CPU work at all, but otherwise, we dump it as a consideration as quickly as we can, for lots of reasons, like not overspecifying a system and overconstraining it, and because it's really, really hard to keep track of time, and generally doesn't bring value commensurate with that complexity. Having built our stack of software and formalisms without very much thought about tracking time precisely, we generally only once at the very end recapture some time information, when we care, via O() analysis, and generally via the use of a whole crapton of explicitly-approximated values, which for what we care about is almost always good enough.... until timing attacks. Timing attacks suck. I think we're just barely beginning to come to grips with how much they suck.
My day dream for fixing Spectre is as follows: Basically double the amount of L1 cache (where the second half doesn't need to be as fast as actual L1 cache), make only the first half usable as cache. When an instruction the CPU speculatively executes an instruction which would replace the content in its L1 cache, first copy the existing content to the second, usually unused, half, and _then_ replace the content of the first half with the new data. Then, if the CPU decides that the branch was correct, just do nothing; if the CPU decides that the branch was incorrect, just copy back the "backup" of the original cache. Copying the cache to and from the "backup" would obviously have to be done really quickly with dedicated hardware, and not be done by going through each byte and copying it, but that should be possible.
Another solution I've thought of, which should probably be easier and/or cheaper: When speculatively executing an instruction, just don't write to cache at all. This would potentially make the speculatively executed instructions slower, but I can't imagine it would have a big effect.
Of course, both of those solutions would just mitigate this specific attack. You're probably exactly correct that timing attacks are going to continue to be a big problem.
[1]: By this I mean that in general, our formal systems dump time as a consideration as quickly as they can. The systems designing the CPUs themselves don't, of course, because time is a big deal in making a modern CPU work at all, but otherwise, we dump it as a consideration as quickly as we can, for lots of reasons, like not overspecifying a system and overconstraining it, and because it's really, really hard to keep track of time, and generally doesn't bring value commensurate with that complexity. Having built our stack of software and formalisms without very much thought about tracking time precisely, we generally only once at the very end recapture some time information, when we care, via O() analysis, and generally via the use of a whole crapton of explicitly-approximated values, which for what we care about is almost always good enough.... until timing attacks. Timing attacks suck. I think we're just barely beginning to come to grips with how much they suck.