linux-kernel - Re: [PATCH] kernel: use ktime_get_real_ts64() to calculate acct.ac

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]

Message-ID: <20191107125559.GI4131@hirez.programming.kicks-ass.net>
Date:   Thu, 7 Nov 2019 13:55:59 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Jan Stancek <jstancek@...hat.com>, linux-kernel@...r.kernel.org,
        ltp@...ts.linux.it, viro@...iv.linux.org.uk,
        kstewart@...uxfoundation.org, gregkh@...uxfoundation.org,
        rfontana@...hat.com
Subject: Re: [PATCH] kernel: use ktime_get_real_ts64() to calculate
 acct.ac_btime

On Thu, Nov 07, 2019 at 01:40:47PM +0100, Thomas Gleixner wrote:
> On Thu, 7 Nov 2019, Peter Zijlstra wrote:

> > +	mono = ktime_get_ns();
> > +	real = ktime_get_real_ns();
> > +	/*
> > +	 * Compute btime by subtracting the elapsed time from the current
> > +	 * CLOCK_REALTIME.
> > +	 *
> > +	 * XXX totally buggered, because it changes results across
> > +	 * adjtime() calls and suspend/resume.
> > +	 */
> > +	delta = mono - tsk->start_time; // elapsed in ns
> > +	btime = real - delta;		// real ns - elapsed ns
> > +	do_div(btime, NSEC_PER_SEC);	// truncated to seconds
> > +	stats->ac_btime = btime;
> 
> That has pretty much the same problem as just storing the CLOCK_REALTIME
> start time at fork and additionally it is wreckaged vs. suspend resume.

It's wrecked in general. It also jumps around for any REALTIME
adjustment.

> So a CLOCK_REALTIME time stamp at fork would at least be correct
> vs. suspend resume.

But still wrecked vs REALTIME jumps, as in, when DST flips the clock
back an hour, your timestamp is in the future.

Any which way around the whole thing is buggered.  The only real fix is
not using REALTIME anything. Which is why I'm loath to add that REALTIME
timestamp at fork(), it just encourages more use.