more fun with AMD and Intel CPUs: Retbleed

[madires]

And we have another one.
Retbleed: Arbitrary Speculative Code Execution with Return Instructions (https://comsec.ethz.ch/research/microarch/retbleed/)

[PKTKS]

I ve got to the point i have even fear messing with cpu microcode flash or upgrade..

Bottom line
Choosing  the olders or the new one bugs...

Paul

[magic]

it’s not good for your health to worry too much

This should become the new slogan of AMtel

[SiliconWizard]

As I said previously, I don't think it is even humanly possible to design a CPU with speculative execution without introducing a bunch of potential exploits.
Meanwhile, that keeps a whole industry busy though.

[magic]

As I said previously, I think it would only take making speculative execution truly free of obvious side effects immediately visible to the software.

The main problem is not that you can run an invalid code, but that the code can store data in cache to be retrieved later by a valid code.

[SiliconWizard]

It's just that, and generations of engineers have just overlooked it. Feel free to do better. Maybe you're not human though.

[brucehoult]

As I said previously, I don't think it is even humanly possible to design a CPU with speculative execution without introducing a bunch of potential exploits.
Meanwhile, that keeps a whole industry busy though.

I think it absolutely is. You just have to not update shared state until the relevant instruction is no longer speculative.

Machines with speculation have obviously made sure they didn't update the architectural registers while an instruction was still speculative, so that any changed could be discarded/rolled back.  You just have to make sure you do the same for branch predictors, TLB entries, branch target caches, return address stacks, cache line replacement/eviction.

Retrofitting that to an existing microarchitecture is not easy, but it should be no big deal for new designs.  You need to provision a few extra entries for each of those resources to hold the speculative state, but (unlike the mitigations on old designs) there is no execution slowdown unless you undersize the number of entries for speculation and have to occasionally stall to wait for a previous instruction to go unconditional.

[magic]

It's just that, and generations of engineers have just overlooked it. Feel free to do better. Maybe you're not human though.

Engineers aren't the sharpest tools in the shed and their managers are greedy aholes, hence we have things like building codes in place.
I guess AMtel proved it's time for CPU design codes. See Bruce's post above if you don't believe me.
The only problem is that politicians are about equally smart, so it will take decades to get there.

Problem?

[SiliconWizard]

Sure idiots are everywhere. Not denying that.
As I said, feel free to design something like that.
I only have slight problems with people lacking some humility and people claiming such and such things (that have never been achieved) are possible while doing nothing to actually prove it. Talk is always cheap.

[magic]

It's worse than idiots. It's people who work 9-5 jobs and need to do exactly enough to cross an item off the manager's checklist. That's how you end up with stuff which does all the things it is supposed to do and then another few things that nobody could possibly foresee it doing

This attitude is all over the place in software and I have little illusion that hardware is much better.


Going back to the topic of speculative execution security, I can on second thought see a certain problem which is genuinely difficult. That is execution time - if you can manipulate a vulnerable program to perform speculative execution which slows it down by a time that varies with some secret data of the program, it might be possible to leak the secret data in some favorable conditions. Not sure how a CPU design could mitigate that. Note that this is not the sort of vulnerability that current CPUs are being exploited for right now (yet ).

[ejeffrey]

That's exactly the sort of vulnerability that is being exploited now.

One form of spectre/meltdown exploit is: try to load some privileged data and act on it.  This would cause a protection fault.  So you wrap it in a branch that will mispredict and be slow to resolve.  When the branch resolves the CPU will throw away the speculative branch including the fault, but it will have updated the branch prediction cache in a way the depends on the secret data.  Then you run through the same code again but not trying to access privileged data and time the branch.  This lets you figure out the state of the branch prediction cache.

[magic]

And this attack wouldn't work if caches and branch predictors are not affected by speculatively executed code, speculative modifications are tracked and undone when the speculation fails. Then, you couldn't store your exfiltrated information in a cache for later retrieval.

But if the same effect could be achieved in one step, a single execution of mispredicted vulnerable code taking different time depending on the secret data, then it seems we are back in game.