linux-kernel - Re: [PATCH 3/3 v11] printk: Add monotonic, boottime, and realtime timestamps

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: <20170917104634.GA442@tigerII.localdomain>
Date:   Sun, 17 Sep 2017 19:46:34 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Mark Salyzyn <salyzyn@...roid.com>, Petr Mladek <pmladek@...e.com>,
        Prarit Bhargava <prarit@...hat.com>
Cc:     linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Christoffer Dall <cdall@...aro.org>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        Joel Fernandes <joelaf@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Olof Johansson <olof@...om.net>,
        Josh Poimboeuf <jpoimboe@...hat.com>, linux-doc@...r.kernel.org
Subject: Re: [PATCH 3/3 v11] printk: Add monotonic, boottime, and realtime
 timestamps

On (09/15/17 07:29), Mark Salyzyn wrote:
> On 09/15/2017 06:28 AM, Petr Mladek wrote:
> > I am still slightly nervous that external tools would need updating.
> > Also they might have troubles to interpret the time stamps especially
> > when the source is changed at runtime via
> > /sys/module/printk/parameters/time.
> My comment below is a rehash/summary:
> 
> In the discussion, it appears that DAC protection is enough to prevent
> flippant changes. The use cases I can imagine for runtime alteration fall in
> two groups, late boot changes after all disks are mounted and the
> application layers have started; or as an aid to debugging where the
> deliberate nature can be accounted for. Change it, erase the logs is the
> KISS solution, so the tools do not have to 'sniff' the stream for dynamic
> changes, likely getting the 'leader' wrong, checking
> /sys/module/printk/parameters/time for the current/last timebase.
> 
> To mitigate the 'leader' issue, or post-mortem/off-machine interpretation,
> really for the debugging corner case IMHO, I had proposed that local, and
> perhaps monotonic, time print as-is as they are almost(?) imperceptibly
> different, but that realtime add a U suffix (to denote time is UTC), and
> that boottime add a B suffix (well, because) so that tools can discern.
> Monotonic could have a M suffix if it is really a stickler. This proposal
> would require more disruptive tool modifications and should be scoped as a
> separate effort. I do expect a debate regarding upper and lower case ...
> 
> I have a patch waiting in the wings here where disruptive time changes
> (suspend/resume/hibernate/restore; maybe date(1), ntpd(8) or embedded
> systems LTE hardware time updates) will report dual timestamps so that
> resynchronization and tracking can happen in post-mortem on the stream, I
> expect to use the above proposal for the 'second' occasional timestamp.

I'm a bit uncomfortable with the "breaks user space" part. since this
is a strictly debugging option, would it be sufficient to store those
extended timestamps as prefixes of every message?
see (sorry for "self-quoting"):
	lkml.kernel.org/r/20170917062608.GA512@...erII.localdomain

each message, thus, will be in the following format

[current header: loglevel, timestamp, etc] [extended printk data] message text

extended printk data can contain your monotonic/etc timestamps, and
anything else.

and then it's up to you how do you grep the messages and process the
extended data. but the point is - user space tools (journald, dmesg,
etc.) stays intact. which is kinda nice.

so we can avoid that chicken and egg problem: we break user space
by merging the patchset but user space people don't want to talk
about any fixes until we break those tools.

	-ss