PROBLEM: tty devices with future timestamps

PROBLEM: tty devices with future timestamps

[Egmont Koblinger]

Hi,

An active terminal line (/dev/pts/N), in about 6% of the cases, has a
future timestamp.

I noticed that the command
  ls -l $(tty)
occasionally prints the timestamp in "month day year" format, rather
than "month day hour:minute". This is what coreutils's "ls" does when
the timestamp is either 6+ months back in the past, or is in the
future. Let's test the "in the future" hypothesis:

  ls -l --full-time $(tty); date +%H:%M:%S.%N
occasionally produces something like
  crw--w---- 1 egmont tty 136, 8 2020-06-27 09:57:28.686473296 +0200 /dev/pts/8
  09:57:28.170717548
Yep, the timestamp of the tty line is a slightly higher value than the
system date at a later point.

Running
  ls -l --full-time $(tty)
in an endless loop causes the seconds to increment in steps of 8, but
the subseconds part remains unchanged, like:
crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:12.686473296 +0200 /dev/pts/8
crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:12.686473296 +0200 /dev/pts/8
crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:20.686473296 +0200 /dev/pts/8
crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:20.686473296 +0200 /dev/pts/8

drivers/tty/tty_io.c : tty_update_time() seems to be responsible for
this jump in 8 seconds, leaving the milliseconds intact.

I think zeroing out the milliseconds in this method would solve the
problem – although then it's maybe inconsistent that at creation time
the device would have subsecond precision which would be gone soon
afterwards. Maybe it's better to create the device with no subseconds
right away? I'll leave it to you guys to decide.

I'm experiencing this on two different machines with Ubuntu 20.04,
using their 5.4.0 kernel. The method setting the seconds but not the
nanoseconds is still present in latest kernel git.

Thanks a lot,
egmont

Re: PROBLEM: tty devices with future timestamps

[Greg KH]

On Sat, Jun 27, 2020 at 10:33:38AM +0200, Egmont Koblinger wrote:
> Hi,
> 
> An active terminal line (/dev/pts/N), in about 6% of the cases, has a
> future timestamp.
> 
> I noticed that the command
>   ls -l $(tty)
> occasionally prints the timestamp in "month day year" format, rather
> than "month day hour:minute". This is what coreutils's "ls" does when
> the timestamp is either 6+ months back in the past, or is in the
> future. Let's test the "in the future" hypothesis:
> 
>   ls -l --full-time $(tty); date +%H:%M:%S.%N
> occasionally produces something like
>   crw--w---- 1 egmont tty 136, 8 2020-06-27 09:57:28.686473296 +0200 /dev/pts/8
>   09:57:28.170717548
> Yep, the timestamp of the tty line is a slightly higher value than the
> system date at a later point.
> 
> Running
>   ls -l --full-time $(tty)
> in an endless loop causes the seconds to increment in steps of 8, but
> the subseconds part remains unchanged, like:
> crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:12.686473296 +0200 /dev/pts/8
> crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:12.686473296 +0200 /dev/pts/8
> crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:20.686473296 +0200 /dev/pts/8
> crw--w---- 1 egmont tty 136, 8 2020-06-27 10:07:20.686473296 +0200 /dev/pts/8
> 
> drivers/tty/tty_io.c : tty_update_time() seems to be responsible for
> this jump in 8 seconds, leaving the milliseconds intact.

Yes, that is way on purpose, as the comment states, this is a security
issue that we had to add.

> I think zeroing out the milliseconds in this method would solve the
> problem – although then it's maybe inconsistent that at creation time
> the device would have subsecond precision which would be gone soon
> afterwards. Maybe it's better to create the device with no subseconds
> right away? I'll leave it to you guys to decide.

What is this "problem" causing today?

> I'm experiencing this on two different machines with Ubuntu 20.04,
> using their 5.4.0 kernel. The method setting the seconds but not the
> nanoseconds is still present in latest kernel git.

Yes, this has been fixed for a while now, it should be present on all
modern systems so that shows they are working properly :)

thanks,

greg k-h

Re: PROBLEM: tty devices with future timestamps

[Egmont Koblinger]

Hi Greg,

> What is this "problem" causing today?

This is probably only a cosmetic issue, rather than a
strictly-speaking bug.  I mean, the tty line works fine, and the 8
second resolution is a nice prevention against security/privacy
issues.  I'm not aware of any misbehavior in any application (which,
of course, does not guarantee that there isn't any).

That being said, the device regularly having a future timestamp (and
in turn, "ls -l" using a different formatting) is totally unexpected,
and made me (and perhaps will make others) think that there must be
something wrong with the system.

Is this a bug in coreutils's "ls"?  (That was my first suspect.)  ...
Or am I experiencing clock skews?  Due to a hardware flaw?  Due to an
ntp problem?   Is there a chance it'll affect some apps too?  ...  Or
what else could it be?  ...  -- I was wondering.

If the code cares enough to update the timestamp at all -- which I
would be fine without, I personally wouldn't mind if it stayed at the
creation time of that tty line, or was always the Epoch --, and cares
enough to reduce the precision -- which I find a good thing --, then I
guess it should also take care of not setting it to a future
timestamp, in order not to cause unexpected end-user results in "ls
-l" and who knows what other tools.


thanks for your consideration,
egmont

Re: PROBLEM: tty devices with future timestamps

[Greg KH]

On Thu, Jul 02, 2020 at 09:16:28AM +0200, Egmont Koblinger wrote:
> Hi Greg,
> 
> > What is this "problem" causing today?
> 
> This is probably only a cosmetic issue, rather than a
> strictly-speaking bug.  I mean, the tty line works fine, and the 8
> second resolution is a nice prevention against security/privacy
> issues.  I'm not aware of any misbehavior in any application (which,
> of course, does not guarantee that there isn't any).

Given that this change has been in linux for over 7 years (was
introduced in 2013), I'm sure we would have been told of any misbehavior
by now :)

> That being said, the device regularly having a future timestamp (and
> in turn, "ls -l" using a different formatting) is totally unexpected,
> and made me (and perhaps will make others) think that there must be
> something wrong with the system.
> 
> Is this a bug in coreutils's "ls"?  (That was my first suspect.)  ...
> Or am I experiencing clock skews?  Due to a hardware flaw?  Due to an
> ntp problem?   Is there a chance it'll affect some apps too?  ...  Or
> what else could it be?  ...  -- I was wondering.
> 
> If the code cares enough to update the timestamp at all -- which I
> would be fine without, I personally wouldn't mind if it stayed at the
> creation time of that tty line, or was always the Epoch --, and cares
> enough to reduce the precision -- which I find a good thing --, then I
> guess it should also take care of not setting it to a future
> timestamp, in order not to cause unexpected end-user results in "ls
> -l" and who knows what other tools.

We are doing a simple "knock the lower bits off and check" calculation
to make this fast, as it needs to be fast.  As for setting it in the
future, I don't think that's what is happening here, you are just
comparing two things that can't be compared as they are not the same
thing.

thanks,

greg k-h

Fwd: PROBLEM: tty devices with future timestamps

[Egmont Koblinger]

(Sorry, resending to include the list)

> As for setting it in the
> future, I don't think that's what is happening here,

Let's forget the "knock the lower bits off" part, it's irrelevant.
For the sake of simplicity, let's just pick a timestamp where those
bits are unset to begin with (i.e. a second divisible by 8).

If you set the seconds to the current seconds, but leave the
nanoseconds intact, whatever non-zero value it has, there's a good
chance that this results in a future timestamp (up to almost 1 second
into the future), as demonstrated in the example in my first mail.

In other words:  If you look at the entire, fine-grained timestamp,
you don't knock the lower bits off.  You update the higher bits, knock
the *middle* bits off, and leave the lower bits intact.

> you are just
> comparing two things that can't be compared as they are not the same
> thing.

Could you please elaborate?  (We're not understanding each other, and
I'm not sure in which direction :-))

My expectation is:  If the kernel maintains the concept of "current
time" which (apart from rare special circumstances like settimeofday()
-- we're not talking about those) always grows, and maintains the
"last access timestamp" of files, it shouldn't be possible that the
automatically updated "last access timestamp" is bigger than the
"current time".

Is this a wrong expectation?  Because if so, then I guess I should
follow up with coreutils devs to reconsider how they decide -- based
on comparing these two values: the file's "last access timestamp" and
the "current time" -- which formatting to pick.  If this is what you
referred to by "comparing two things that can't be compared" then what
they do is conceptually wrong.

> as it needs to be fast.

Zeroing out the nanoseconds -- maybe just once, at tty creation -- is
fast, and eliminates the possibility of future timestamps.

(s/milli/nano in my previous mails)


cheers,
egmont