linux-kernel - Re: [RFC patch 6/7] printk: Store mono/boot/real time 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: <20171123133620.rck6dlchuujp4aut@pathway.suse.cz>
Date:   Thu, 23 Nov 2017 14:36:20 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Linus Torvalds <torvalds@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Prarit Bhargava <prarit@...hat.com>,
        Mark Salyzyn <salyzyn@...roid.com>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Joe Perches <joe@...ches.com>
Subject: Re: [RFC patch 6/7] printk: Store mono/boot/real time timestamps

On Wed 2017-11-15 19:15:37, Thomas Gleixner wrote:
> To allow reliable timestamp correlation, replace the clock MONOTONIC based
> timestamp in the printk ringbuffer entries with a collection of MONOTONIC,
> BOOTTIME and REALTIME timestamps.
> 
> This does not change the textual output, as this is a separate issue. For
> tools which access a vmcore the new timestamp fields are separately
> exported by name so the tools do not have to gain knowledge about struct
> system_timestamps. The existing 'ts_nsec' timestamp, which is used by
> existing tools is mapped to the clock MONOTONIC entry of the timestamp
> collection.

OK, we do this to do not break existing users. But what are
the acceptable ways to make this information available?

IMHO, the right solution is that every reader would need to
explicitely ask for the extended format:

  + /dev/kmsg: ask for extended output via ioctl()

  + syslog: ask for extra timestamps by LOG_*_TIMESTAMP options
	    of the openlog() syscall. It would be similar
	    to LOG_PID.

  + console: extend to console= parameter format, e.g.
            console=name[,options][/t]

            , where /t would cause showing all the timestamps
	    in the following format

            [xxxxx.xxxxxx][b=xxxxx.xxxxxx][r=xxxxx.xxxxxxx] <message>

Would this be acceptable, please?
Do you have other/better ideas, please?

Best Regards,
Petr