linux-kernel - Re: [PATCH] um: time-travel: fix time going backwards

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 23 Oct 2023 09:33:09 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Vincent Whitchurch <Vincent.Whitchurch@...s.com>,
        "anton.ivanov@...bridgegreys.com" <anton.ivanov@...bridgegreys.com>,
        "richard@....at" <richard@....at>
Cc:     "linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kernel <kernel@...s.com>
Subject: Re: [PATCH] um: time-travel: fix time going backwards

On Mon, 2023-10-23 at 07:08 +0000, Vincent Whitchurch wrote:
> On Fri, 2023-10-20 at 16:47 +0200, Vincent Whitchurch wrote:
> > In basic time travel mode, I sometimes see "time goes backwards" panics
> > like the one below:
> > 
> >  Kernel panic: time-travel: time goes backwards 161689340000492 -> 161689339869814

Ouch.

> >  Call Trace:
> >   panic+0x1a1/0x3d7
> >   time_travel_update_time.cold+0xe9/0x133
> >   timer_read+0xc1/0x100
> >   ktime_get+0x10c/0x200
> >   copy_process+0x1899/0x2230
> >   kernel_clone+0x57/0x7a0
> >   kernel_thread+0x4a/0x50
> >   kthreadd+0x116/0x190
> > 
> > The problem is a race between time_travel_handle_real_alarm() and
> > timer_read().  time_travel_handle_real_alarm() changes the time after
> > time_read() reads the current time but before time_travel_update_time()
> > has had a chance to add the end event.
> > 
> > Fix this by doing the time read and event add atomically with respect to
> > time_travel_handle_real_alarm().
> 
> Further testing resulted in hitting the BUG_ON(time_travel_time !=
> e->time) so looks like this needs some more work.  
> 

Yeah this is a tricky area, I fought with it for quite a while too,
seems we're not done yet ;-)

We mostly use time-travel=ext mode these days, so our system may not be
as susceptible to it? But not sure, in some cases it runs with just a
single instance, and that should be pretty much the same due to the
free-until information.

Do you have a specific workload that tends to reproduce this?

johannes