Why doesn't Fuchsia restrict access to clocks to prevent untrusted processes from performing timing attacks?

Question

A timing attack is when hostile code figures out some information its not supposed to have by measuring how long it takes other, more trusted processes, to perform known actions over private data.

Advocates of the object-capability model generally recognize that you can reduce timing attacks by not providing clocks by default, requiring a process to have been given a clock capability, otherwise denying them any way of measuring the passage of time. Given that Fuchsia is very object-capability type of OS, why are clocks available by default?

Answer 1

This is a fair question, and this is an indirect answer as it does not answer why clock access is available.

Specifically when it comes to timing attacks, a clock is merely a convenience, it is not a necessity for recording timing information in most scenarios, as other mechanisms such as counting competing spinning operations or comparing timing to other operations are often sufficient, albeit sometimes harder to setup.

Other practical issues arise, such as it being desirable on the path you describe to also restrict threads, which also have some deep ties to this problem space by way of commonly used standard library mutexes having dependencies on wall time. The implications here become somewhat problematic as attempting to pull all such access out introduces impediments to startup of very common runtimes and, depending on implemention details many designs may also impede performance of common programs.

--

Edit: I should also add, we have mailinglists, here: fuchsia.dev/fuchsia-src/contribute/community/get-involved This question would be welcome there, and it is possible that so would a proposal to introduce some capabilities around this. The best place to start the the discussion is on those mailinglists. I hope we see you there!