lsds
Time source update should be configurable
Currently, the external time source has a periodic tick at a hard-coded constant rate. This tick rate caps the maximum clock drift between the host and guest (the tick rate is the lower bound on the maximum drift, the upper bound is defined by scheduling latency on the host).
Currently, the value is hard coded at 0.5ms. We are probably not actually getting this accuracy, but we are requiring the timer thread to wake up very often. We can trade a small amount of timer precision for lower latency.
The current value is required for one of the LTP tests, but a lower value is unlikely to cause problems for most real code.
@wintersteiger / @prp, for this to be configurable we need to provide a configuration option for it. Do you think this should be part of the attested or non-attested configuration? This will affect behaviour, but we don't have a way of validating that the untrusted host is doing what it promises, so my leaning is towards untrusted.
@davidchisnall yes, any configuration parameter that affects enclave execution but cannot be checked by the enclave and thus can be changed behind the back of the enclave should not be part of the attestation. Instead, this should be part of what we call the host_config, which only affects the launcher. (Does the enclave need to know this value?)
Doesn't a high tick rate affect performance, as we are essentially dedicating one core to this?
A whole core just for the ticker? That seems a bit excessive.
Time is always tricky. Any enclave code basically has to assume that it can't rely on any timing information from the host, so I don't think it makes sense to attest it. Having a host-side option for it is the right thing to do I think.
A core is not dedicated to the timer ticking, a host pthread is dedicated to it. That thread sleeps for 0.5ms, then wakes, updates the value, and loops. The more often we wake up this thread, the less time the CPUs have for ethreads.