Karel Kulhavy wrote:
This kind of security design is assuming favourable constellation of uncontrollable environmental noises to scramble the information we are knowingly leaking. It's basically a snake oil. We have no proof that under every conceivable circumstances the noises will be present in a way that completely masks the information leak.
Or, on exit to user mode, flush the caches, TLB, and branch target cache. This would kill any such leaks. Or, compile to PIC, and use a random number generator to reassign load addresses every time the kernel is loaded, and break up the kernel into chunks so the addresses used by the keyboard code are unknown. Or, for any process which is CPU bound, sample its instruction stream and if it is using instructions which probe CPU resources, kill the process. Or, who knows... there are probably dozens of ways to prevent leakage of this kind. It's still amazingly improbable that any information could usefully get through this way. "Banging on the walls" deliberately trying to transfer information from process to process can only send a few bits a second in most cases, which is why getting information about computationally intensive things like cryptography might work.
