Re: PROBLEM: tty devices with future timestamps

[Greg KH <greg@kroah.com>]

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