LWN: Comments on "Time namespaces"

Time namespaces

yxejamir — Mon, 08 Oct 2018 18:50:56 +0000

Would any of the proposed changes allow to freeze time inside a namespace? It's somewhat realted to the question of reproducible builds raised before, because it will guarantee all timestamps to be the same.

Time namespaces

mathstuf — Thu, 27 Sep 2018 21:01:01 +0000

Well, then your build also needs to go at the same speed as the other builds. If I build on an RPi, I'm going to get a different embedded timestamp at the start and end compared to a Xeon running QEMU.

Time namespaces

cew5550 — Thu, 27 Sep 2018 14:24:00 +0000

Exactly true and what I was thinking as well. About the only real issue is going back in time - that can break things.

Time namespaces

mhelsley-vmw — Thu, 27 Sep 2018 00:11:10 +0000

I wonder if this could also be useful when kicking off reproducible builds. Lots of software/package/container build scripts use the current time, at some granularity, to stamp (parts of) a build. Being able to set a specific build time without having to modify thousands of bespoke build scripts might be handy for anyone who wants to verify that builds can indeed be reproduced.

Time namespaces

rriggs — Mon, 24 Sep 2018 14:49:50 +0000

The primary reason I would use time namespaces is to test code around DST changes, leap seconds, leap years, etc. It's rather difficult to mock that stuff because a lot of code acquires the time from system calls. I've done by overriding libc functions in an LD_PRELOADed library, but that doesn't provide the same coverage that changing the actual system time does.

Expired Certificates

KaiRo — Mon, 24 Sep 2018 12:30:04 +0000

One of the problems is that most certificate checks in software do not check revoking information, and even the sources for revoking information (CRLs, OCSP, etc.) have various issues, including privacy leaks and more. That's one reason why expiry has more weight than it should have in theory, because it puts a time limit on the issues around revocation.

Time namespaces

k8to — Mon, 24 Sep 2018 07:54:19 +0000

I'm not sure I'm understanding you properly. I see programs break all the time if they get descheduled longer than an engineer thought was reasonable.

I also see programs break just because the system clock jumps ahead for some reason (administration, hardware flaws, etc), or because the delta in the wallclock time between two systems is stable but over "what is reasonable".

Maybe you weren't talking about these scenarios? They're bad software for sure, but in my experience most software is bad software.

Time namespaces

rweikusat2 — Sun, 23 Sep 2018 18:52:31 +0000

Quoting the ntpd documentation (-x option)

Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete.

Leaving this non-possibilty aside, this doesn't help with a real-time bound task. Eg, using an example I'm familiar with, an IKEv1 ISAKMP SA usually has a fixed, negotiated lifetime and there's another party to it. It's not possible to stop the task manageing the SA and later restart it in a virtual past because the lifetime of the SA will end on time, regardless of any local clock fudging. The outcome will be a VPN communication breakdown until the 'confused' IKE task has again caught up with the real universe outside of it.

Time namespaces

kiryl — Sun, 23 Sep 2018 17:36:38 +0000

Of course it's possible. ntpd is able to adjust time from wrong to right in a safer manner.

Expired Certificates

rweikusat2 — Sun, 23 Sep 2018 16:57:26 +0000

A certificate as two time attributes called "not before" and "not after" which form the bounds of "certificate lifetime". That's a property of the certificate and has absolutely no relation to "domain ownership". In case of a domain changing owner, not that this would be applicable to the camera case, old certificates would probably be revoked, that is, put on a special "this certificate isn't considered valid anymore" list published by a CA (simplification).

'Bad certificates' would also usually be dealt with by revocation. Standard lifetime of commercial certificates is a year and "Oh well, the guy who pretends to be your bank in order to rob your account will be forced to stop next year!" wouldn't exactly be fit-for-purpose as security policy here.

Time namespaces

rweikusat2 — Sun, 23 Sep 2018 16:50:34 +0000

Well, yes. But if they were scheduled for some absolute time, they should fire. It's not generally possible to stop a real-time bound task and restart it much later without wreaking some havoc on it.

Time namespaces

kiryl — Sun, 23 Sep 2018 16:08:20 +0000

> It's also difficult to imagine an application which could break because it resumes execution at some unspecified time in future relative to when it was stopped.

All sorts of timeouts can fire up just because the application was resumed few hours in the future.

Expired Certificates

Sesse — Sun, 23 Sep 2018 14:51:11 +0000

Other reasons why certificates expire include that the domain may have been transferred to another entity. And if somebody manages to generate a bad certificate somehow, one wants to limit the amount of damage that can be done.

Expired certificates are also generally not part of OSCP, so it's hard to revoke them in practice.

Expired Certificates

rweikusat2 — Sun, 23 Sep 2018 13:43:54 +0000

There's no technical reason why one shouldn't trust an expired certificate. 'A certificate' is a public key plus some metainformation which both have been digitially signed utilizing some usually unrelated private key (if the private key corresponding to the public key in the certificate has been used, the certificate is said to be self-signed). The owner of the certificate will also have the secret private key corresponding with the public key and hence, someone who has access to the certificate can create messages only the certificate owner can decrypt. It's considered prudent to change encryption keys regular, that's why certificates "expire". But that's just encouraging a key change (which implies generating a new certificate) and doesn't enforce it: Unless the private key has been compromised, there's no need to stop using it.

Time namespaces

dtlin — Fri, 21 Sep 2018 21:47:34 +0000

If you just need to adjust the time for a single browser, libfaketime would likely be easier.

Chrome explicitly tries to guard against wrong client time and might not cooperate with your time tweaking either way, though.

//chromium/src/components/network_time/network_time_tracker.cc

// Network time queries are enabled on all desktop platforms except ChromeOS,
// which uses tlsdated to set the system time.

//chromium/src/components/ssl_errors/error_classification.cc

  if (now_system < build_time - base::TimeDelta::FromDays(2)) {
    build_time_state = CLOCK_STATE_PAST;
  } else if (now_system > build_time + base::TimeDelta::FromDays(365)) {
    build_time_state = CLOCK_STATE_FUTURE;
  }

Time namespaces

amarao — Fri, 21 Sep 2018 21:31:04 +0000

I just realized a scenario where time namespaces are excellent. It's the access to expired SSL. Yes, you shouldn't trust expired certificates. But what if some device have hardcoded certificate and it expired in 2016? Device (f.e. ip camera made of chainizium) is good and can be used. But it had certificate expiring on 2016... Currently it's pain in the arse to use such stuff, and every next browser version made it harder and harder. With time namespaces I can just run a browser instance in namespace with eternal 2015 and use such device with no issues.

Time namespaces

rweikusat2 — Fri, 21 Sep 2018 21:10:48 +0000

That was just me being dense. Thanks for the additional explanation.

Time namespaces

corbet — Fri, 21 Sep 2018 20:47:08 +0000

I guess I wasn't clear enough on that...having a bad week, it seems.

System times are based on internal clocks that will vary across systems, even when time synchronization is in place. If you're not careful, a migrated process has a high probability of seeing CLOCK_MONOTONIC going backward, for example, which is going to create confusion. People do have reasons for doing this kind of work...

Time namespaces

rweikusat2 — Fri, 21 Sep 2018 20:33:26 +0000

The assumption that "containers" are surely not part of a distributed system running on different internet nodes which is based on the notion of "the time" as commonly understood by people who don't seriously believe this was an evil conspiracy of railway operators of about 150 years ago seems a bit ... optimistic.

It's also difficult to imagine an application which could break because it resumes execution at some unspecified time in future relative to when it was stopped. This a common-place situation in a preemptive multitasking system, after all. What could conceivably cause problems here is moving application between systems whose ideas of "the time" differ because of "run ntpdate from cron" disease or ignoring clock drift altogether, IOW, the application suddenly finds itself in the past of it's earlier state.