3 ms·

> Having the clock be an ambient authority leaves the system open to easy timing attacks via implicit covert channels. "leaves the system open" are strong word

by temac 9y ago

> Having the clock be an ambient authority leaves the system open to easy timing attacks via implicit covert channels. "leaves the system open" are strong words. If you allow only threads you have got high precision clocks as a bonus in practice. Still it could be useful to have environments so restricted that even restricting clock services could be useful, but I would certainly not call the lack of capability there a very big issue. Plus designing those would be hard anyway: does not having this capa would mandatorily prevent from even creating threads (or pretty much all kind of objects which can be retargeted to infer time, which means tons of them, and maybe it being the case or not will depend on the implementation)? Maybe it is better to not pretend that a capability exists for getting the time if you will probably be able to get it without said capability?

naasking 9y ago
Clock access via a handle has other uses beyond security. For instance, you could use it for deterministic replay of a process. The point being, any abilities that aren't reified as explicit handles are ambient in the environment, and so make isolation and virtualization harder. Consider how you would virtualize the clock now that it's part of the process's implicit environment instead of an invocation made via a handle.
- adrianratnapala 9y ago
  This is a good point. I've seen in practice systems where in hindsight it would have been nice if we had used some virtual clock rather than the machine clock. An OS could help by making the virtualisable clock the default API. Still there will be applications that want a high-precision or low overhead clock. But those applications should buy into the trade-off explicitly.
  - naasking 9y ago
    Agreed! For instance, a realtime clock like you mention could be reified as a clock factory handle, which you must be explicitly given and must invoke to install the clock at a fixed or configurable address (or something along those lines). This is opt-in, efficient and virtualizable.

by temac 9y ago

naasking 9y ago

Clock access via a handle has other uses beyond security. For instance, you could use it for deterministic replay of a process. The point being, any abilities that aren't reified as explicit handles are ambient in the environment, and so make isolation and virtualization harder. Consider how you would virtualize the clock now that it's part of the process's implicit environment instead of an invocation made via a handle.

adrianratnapala 9y ago
This is a good point. I've seen in practice systems where in hindsight it would have been nice if we had used some virtual clock rather than the machine clock. An OS could help by making the virtualisable clock the default API. Still there will be applications that want a high-precision or low overhead clock. But those applications should buy into the trade-off explicitly.
- naasking 9y ago
  Agreed! For instance, a realtime clock like you mention could be reified as a clock factory handle, which you must be explicitly given and must invoke to install the clock at a fixed or configurable address (or something along those lines). This is opt-in, efficient and virtualizable.