linux-kernel - Re: [PATCH next v2 1/2] printk: avoid and/or handle record truncation

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: <20201001072659.GB17717@alley>
Date:   Thu, 1 Oct 2020 09:26:59 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Joe Perches <joe@...ches.com>
Cc:     John Ogness <john.ogness@...utronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH next v2 1/2] printk: avoid and/or handle record truncation

On Wed 2020-09-30 08:25:24, Joe Perches wrote:
> On Wed, 2020-09-30 at 11:07 +0206, John Ogness wrote:
> > If a reader provides a buffer that is smaller than the message text,
> > the @text_len field of @info will have a value larger than the buffer
> > size. If readers blindly read @text_len bytes of data without
> > checking the size, they will read beyond their buffer.
> > 
> > Add this check to record_print_text() to properly recognize when such
> > truncation has occurred.
> > 
> > Add a maximum size argument to the ringbuffer function to extend
> > records so that records can not be created that are larger than the
> > buffer size of readers.
> > 
> > When extending records (LOG_CONT), do not extend records beyond
> > LOG_LINE_MAX since that is the maximum size available in the buffers
> > used by consoles and syslog.
> 
> I still think it better to support backspace by rewinding
> the buffer rather than truncation of the output.

IMHO, backspace support is not worth the complexity. It might do
some fancy animation on console but it does not bring any advantage
in static logs (dmesg, journalctl).

It is possible that it worked in the past when the log buffer was
just an array of characters that were pushed to the console when
they appeared.

But I am pretty sure that it has stopped working many years ago when
the buffer 7ff9554bb578 ("printk: convert byte-buffer to
variable-length record buffer").

Best Regards,
Petr