CPU timing attacks and CloudABI

[valpackett]

For the last few days, everyone has been talking about the new branch prediction/cache/timing attacks. I've been thinking, maybe this is a good opportunity for CloudABI?

• Time Stamp Counter access can be disabled — is it getting disabled in CloudABI applications?
• browsers are lowering timer precision — I think typical web servers also do not need high accuracy timers, so maybe CloudABI should allow the user to say something like max_timer_precision: 1ms in the YAML file to limit the maximum resolution of cloudabi_sys_clock_time_get(). Also something like randomize_clocks: true to make cloudabi_sys_clock_time_get() report fuzzy time.
• maybe KPTI-style mitigations should always apply for CloudABI binaries, regardless of whether they're enabled globally in the system (like with Linux's boot flag)?

[EdSchouten]

Hi there,

I would very much welcome work in the area of the interaction between Spectre/Meltdown and CloudABI and see what we can do to improve security. Some random remarks:

• Timestamp counter access disabling: right now we don't do anything special here. We simply (have to) apply the same policy that the host operating system (FreeBSD, macOS, etc) has.

• Lowering time precision: I agree that such a feature would be interesting to have, though I personally think this should not be a process-level option. CloudABI is a capability-based system. Adding per-process/user/... knobs is orthogonal to this idea.

  I would rather see that we introduce something like a 'clock fd' that corresponds with some kind of clock source. We could get away with letting clock_t be an int, so that clock_gettime(), etc. effectively takes a file descriptor. Eventually we could even consider removing CLOCK_MONOTONIC and CLOCK_REALTIME, meaning that if a process does not possess any clock fds, it simply has no concept of time. Another advantage is that it makes it possible to pass in clocks that purposefully return values in the past/future, which may be nice to have for testing purposes. On the other hand, it may cause lots of confusion.

  The downside is that this will break any code that makes use of APIs that don't take explicit (variable) clock sources, such as time(), gettimeofday(), which is a lot of code.

• KPTI: I'd rather not go into that direction. The idea behind CloudABI is to provide a clean API against which programs can be built, allowing operating systems to easily run them in a strongly sandboxed mode if they want to. Enforcing that KPTI is used introduces a requirement in the other direction: it requires that operating systems are hardened against malicious programs. This is outside the scope of CloudABI. It is something that should in my opinion be guaranteed regardless of whether CloudABI is used.

[EdSchouten]

Correction: there is no need to make clockid_t an integer. In the current implementation, it is already defined as a struct __clockid *. On the C library side, we could introduce a clock_from_fd() that takes a file descriptor and turns it into a clock object.