0

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?

mako
  • 1,201
  • 14
  • 30

1 Answers1

0

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!

raggi
  • 1,290
  • 9
  • 12
  • Yes, of course if you were trying to prevent timing attacks you would limit access to that sort of thread stuff as well. Could you give an example of a situation where it's important for a program to have that capability, (to compare the order of completion of threaded processes, yes?) I don't think I've come across one, myself. I wonder how many programs need it. – mako Mar 28 '21 at 01:32
  • Although you might make a case that they shouldn't do this, a lot of modern mutex and associated implementations these days use short spin speculation based on relatively fine grained clocks. Take a look at any commonly used c++ libraries for examples. The Go runtime also, as another example, uses a short spinning lock in the middle of it's scheduler. – raggi Mar 29 '21 at 03:26
  • I should also add, we have mailinglists, here: https://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! – raggi Mar 29 '21 at 03:34