48 ms·

> > Calls which have no limitations, of which there are only a very few, for example zx_clock_get() and zx_nanosleep() may be called by any thread. > > Having t

by lambda 8y ago

> > Calls which have no limitations, of which there are only a very few, for example zx_clock_get() and zx_nanosleep() may be called by any thread. > > Having the clock be an ambient authority leaves the system open to easy timing attacks via implicit covert channels. I'm glad these kinds of timing attacks have gotten more attention with Spectre and Meltdown. Capability security folks have been pointing these out for decades. Is there a way that these could mediated by a capability without having to incur syscall overhead? One of the reasons that these are bare functions is likely that they are in the vDSO, and are just simple function calls which can access some shared memory which contains the clock time. I suppose you could simply not give some processes access to that memory, and have the functions in the vDSO just return an error in that case. I know that there was a time when the Linux kernel changed how their vDSO handling worked, so older glibcs would have to fall back to making an actual syscall for gettimeofday, and that seriously affected performance on some servers that updated the kernel without updating glibc. These functions are called quite often on servers for logging purposes, so adding overhead to make them go through a syscall can be a big performance hit. > I'm hesitant to endorse any system calls with ambient authority, even if it's scoped by context like these. It's far too easy to introduce subtle vulnerabilities. For instance, these calls seem to permit a Confused Deputy attack as long as two processes are running in the same Job. Yeah, this is a bit odd. In fact, it's not just these syscalls which have ambient authority, there's a whole list in https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls/job_set_policy.md https://fuchsia.googlesource.com/zircon/+/master/docs/syscal... and it includes VMOs, ports, sockets, and so on. It does seem somewhat odd to have this capability system, but then ignore it for a number of actions which can only be limited at the job level.

naasking 8y ago
> Is there a way that these could mediated by a capability without having to incur syscall overhead? Is that even warranted? What applications can you imagine would make so many clock calls so as to incur noticeable overhead? Your example of logging costs might work, but I'm very skeptical that user/kernel transition costs for a clock call would drown out the costs of writing the log entry to disk. But to answer your question directly, the ability to access the clock in a shared memory segment can itself be reified as a handle that's granted to a process. The process would then issue a map operation and provide an address at which to map the clock (or you could just always map it at the same address too if that's preferable for some reason).
- kllrnohj 8y ago
  clock_gettime is extremely heavily used by nearly everything. Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. Any form of media uses it heavily, as does self-monitoring to look for performance regressions in the wild. You might be shielded from this depending on what level you're working at, but there's a reason that vDSO exists basically solely for clock_gettime, too. Yes it allows for timing attacks, but you can't really avoid that, either, not without utterly crippling your platform.
  - naasking 8y ago
    > Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. That seems strange to me. Why would you use the clock/gettime call for that instead of a work counter of some sort?
    - kllrnohj 8y ago
      I meant time-delayed. Eg, run this in 10ms type of thing. How else would you do things like exponential backoff?
      - naasking 8y ago
        Right, but your original statement was about clock_gettime, hence my confusion. Something like sleep() is an operation on your own schedule, not an operation on a global system clock. That's not nearly as problematic. Consider if you wanted to virtualize a process, say to deterministically replay it to trigger a fault or something. sleep(100 ticks) doesn't require additional kernel support for virtualization, but an ambient clock requires a lot of extra kernel support. If the clock were only accessible via a handle, then you could proxy invocations on the handle without any extra support in the kernel. See my other comment for more details: https://news.ycombinator.com/item?id=16817462 https://news.ycombinator.com/item?id=16817462
        kllrnohj 8y ago
amluto 8y ago
Timing in particular is tricky. On Linux, you could use the vDSO for high-resolution timing but, from an attack perspective, it’s a red herring. Any serious attacker would use RDTSC, RDPMC, threads and shared memory, or some other hardware mechanism. On x86, RDTSC and RDPMC are controllable by the scheduler (there are bits to turn them off), but it doesn’t really fit in a capability model.
- rdtsc 8y ago
  > you could use the vDSO for high-resolution timing but, from an attack perspective, it’s a red herring. Any serious attacker would use RDTSC, Good point. I was going to say that in general the vDSO is just rdtsc + an offset applied. However they insert a barrier before it usually. That maybe or many not be helpful so I would probably still use rdtsc by itself.

by lambda 8y ago

naasking 8y ago

> Is there a way that these could mediated by a capability without having to incur syscall overhead? Is that even warranted? What applications can you imagine would make so many clock calls so as to incur noticeable overhead? Your example of logging costs might work, but I'm very skeptical that user/kernel transition costs for a clock call would drown out the costs of writing the log entry to disk. But to answer your question directly, the ability to access the clock in a shared memory segment can itself be reified as a handle that's granted to a process. The process would then issue a map operation and provide an address at which to map the clock (or you could just always map it at the same address too if that's preferable for some reason).

kllrnohj 8y ago
clock_gettime is extremely heavily used by nearly everything. Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. Any form of media uses it heavily, as does self-monitoring to look for performance regressions in the wild. You might be shielded from this depending on what level you're working at, but there's a reason that vDSO exists basically solely for clock_gettime, too. Yes it allows for timing attacks, but you can't really avoid that, either, not without utterly crippling your platform.
- naasking 8y ago
  > Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. That seems strange to me. Why would you use the clock/gettime call for that instead of a work counter of some sort?
  - kllrnohj 8y ago
    I meant time-delayed. Eg, run this in 10ms type of thing. How else would you do things like exponential backoff?
    - naasking 8y ago
      Right, but your original statement was about clock_gettime, hence my confusion. Something like sleep() is an operation on your own schedule, not an operation on a global system clock. That's not nearly as problematic. Consider if you wanted to virtualize a process, say to deterministically replay it to trigger a fault or something. sleep(100 ticks) doesn't require additional kernel support for virtualization, but an ambient clock requires a lot of extra kernel support. If the clock were only accessible via a handle, then you could proxy invocations on the handle without any extra support in the kernel. See my other comment for more details: https://news.ycombinator.com/item?id=16817462 https://news.ycombinator.com/item?id=16817462
      - kllrnohj 8y ago

amluto 8y ago

Timing in particular is tricky. On Linux, you could use the vDSO for high-resolution timing but, from an attack perspective, it’s a red herring. Any serious attacker would use RDTSC, RDPMC, threads and shared memory, or some other hardware mechanism. On x86, RDTSC and RDPMC are controllable by the scheduler (there are bits to turn them off), but it doesn’t really fit in a capability model.

rdtsc 8y ago
> you could use the vDSO for high-resolution timing but, from an attack perspective, it’s a red herring. Any serious attacker would use RDTSC, Good point. I was going to say that in general the vDSO is just rdtsc + an offset applied. However they insert a barrier before it usually. That maybe or many not be helpful so I would probably still use rdtsc by itself.