Hubris.

I've been trying to wrap my head around for over a decade how these side channel attacks between L1 caches and branch prediction caches don't happen.

Wish I had published my November 2016 research into function call leaks. CPU registers leaking information between function calls is still a huge unmitigated issue.

You want to shit yourself, goose GCC or LLVM to instrument your function calls with a dump of everything in CPU registers before they start. Do this with libraries that people blindly link in dynamically.

In the world of crypto we've known about cache timing issues forever. Writing cryptographic algorithm implementations so that they are constant-time is really hard, but also always the goal nowadays, as timing side-channels are and long have been a big deal.

What's new here is exploitation of speculative execution (branch prediction). It takes what was already difficult in the world of crypto to a new level of difficulty (or maybe not; it looks like the fix for this will be to effectively disable branch prediction in sensitive code, or even preferably by default and enable it only where it's necessary and safe).

I think you need to disable branch prediction on any core that has access to sensitive memory, not just during the execution of sensitive code. It's 'untrusted' code running on the same machine that you need to worry about.

> CPU registers leaking information between function calls is still a huge unmitigated issue.

How is that a security issue? It's in the same process.

A process to which one has invited unvetted visitors ("blindly link in dynamically"). I'm not particularly qualified to agree or disagree, but I think that's where parent is going with this. I'm with you, though, in that I can read the registers from a previous function call, but I'm already in the process so do I even need to work that hard? I eagerly await an answer from those better qualified than I. :-) (And maybe you're that person, quacj, dunno.)

Static linking too. Most of us rely on library code maintained by others we trust. Reads from registers that should be empty isn't flagged by most code auditing software.

Say you have a memory pointer to sensitive info in a CPU register.

Could the subroutine troll through memory and find it? Yes, but it would be orders of magnitude harder than having that pointer in a register.

Better example is if you are using 64 bit ints in registers as security tokens. Those should be zeroed after use and the compiler needs to not accidentally optimize away zeroing them.

It's a subroutine. It has access to the entire program. There is no security boundary there. If you link against code, it's inside your security boundary. This is not something that can be secured.

It doesn't matter. If you call a library function you're giving that library license to run arbitrary code in your address space. An RPC is another matter.

Do you have a proof of concept you can share for this type of attack?

I don't quite see how an attacker would take advantage of this is a real-world scenario.

Yes, John Deere tractor running Windriver Linux; heavy use of dbus and Qt. Any compromised tractor app vendor could inject it.

Could probably reproduce from upstream Yocto distro and the free version of Qt.

Much larger attack surfaces to worry about like their craptastic security around USBs that farmers stick in to read maps.

Think of system calls too.

Are you referring to callbacks from kernel mode to user mode?