Notes from the Intelpocalypse

Posted Jan 4, 2018 11:36 UTC (Thu) by nix (subscriber, #2304)
In reply to: Notes from the Intelpocalypse by kentonv
Parent article: Notes from the Intelpocalypse

I just babbled about possible high-res-timer-related mitigations here: <https://lwn.net/Articles/742867/>. All a bit painful (and with user-visible consequences if you actually *need* accurate high-res times many times a second) but a lot less painful than the reported KPTI slowdown, ISTM.

Notes from the Intelpocalypse

Posted Jan 4, 2018 19:40 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

It won't work, unless you also disable multi-threading totally. You can cobble up a high-resolution timer by having one thread do N writes to a buffer and the other thread observing a value at a fixed offset within this buffer.

Notes from the Intelpocalypse

Posted Jan 4, 2018 20:19 UTC (Thu) by bronson (subscriber, #4806) [Link] (4 responses)

If you have enough time to perform the attack, it won't work period. Even if I'm only allowed a very low resolution timer, I can compensate by performing lots of operations and running some statistics.

(In addition to being extremely well known for crypto timing attacks, it's how LIGO can measure 1/1000th of the width of a proton.)

Notes from the Intelpocalypse

Posted Jan 4, 2018 20:37 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

"Performing lots of operations and running some statistics" probably slows the attack from a 500KiB/s flood down to a trickle, though. It seems a useful amelioration, at least.

Notes from the Intelpocalypse

Posted Jan 4, 2018 21:44 UTC (Thu) by roc (subscriber, #30627) [Link] (2 responses)

But the multithreading approach Cyberax noted is a showstopper. Note that it also works with multiple single-threaded processes that share memory. It could even be made to work without shared memory, just with one process writing a counter to a file and another process reading it.

Even if you think you can fix all those (I don't see how), it's difficult to be confident people aren't going to come up with new ways to estimate time. And each mitigation you introduce degrades the user experience.

Notes from the Intelpocalypse

Posted Jan 4, 2018 22:55 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Another one I've heard is to submit an asynchronous disk request and time its completion.

Notes from the Intelpocalypse

Posted Jan 5, 2018 17:26 UTC (Fri) by anselm (subscriber, #2796) [Link]

One important observation with covert channels is that in general, covert channels cannot be removed completely. Insisting that a system be 100% free of all conceivable covert channels is therefore not reasonable.

People doing security evaluations are usually satisfied when the covert channels that do inevitably exist provide such little bandwidth that they are, in practice, no longer useful to attackers.