linux-kernel - Re: [PATCH] printk: Userspace format enumeration support

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:   Sat, 6 Feb 2021 21:21:52 +0000
From:   Chris Down <chris@...isdown.name>
To:     Joe Perches <joe@...ches.com>
Cc:     Petr Mladek <pmladek@...e.com>, linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        John Ogness <john.ogness@...utronix.de>,
        Johannes Weiner <hannes@...xchg.org>,
        Andrew Morton <akpm@...ux-foundation.org>, kernel-team@...com,
        Steven Rostedt <rostedt@...dmis.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jason Baron <jbaron@...mai.com>,
        Kees Cook <keescook@...omium.org>, linux-api@...r.kernel.org
Subject: Re: [PATCH] printk: Userspace format enumeration support

Joe Perches writes:
>On Fri, 2021-02-05 at 22:25 +0000, Chris Down wrote:
>> Petr Mladek writes:
>> >   + <module> is already optinaly added by pr_fmt() to the printed strings
>> >     as:  pr_fmt(): ...
>>
>> pr_fmts are not consistently used across the kernel, and sometimes differ from
>> the module itself. Many modules don't use it at all, and we also don't have it
>> for pr_cont. Just picking some random examples:
>>
>>      % grep -av vmlinux /proc/printk_formats | shuf -n 10
>>      mac80211,6%s: mesh STA %pM switches to channel requiring DFS (%d MHz, width:%d, CF1/2: %d/%d MHz), aborting
>>      thinkpad_acpi,c N/Athinkpad_acpi,c %dthinkpad_acpi,5thinkpad_acpi: temperatures (Celsius):thinkpad_acpi,3thinkpad_acpi: Out of memory for LED data
>
>I don't understand this format.
>
>"Out of memory for LED data" is a single printk ending with a '\n' newline
>I expected this to be broken up into multiple lines, one for each printk
>that endsd in a newline.

Hmm, that's just a manifestation of directly using `shuf` without doing the 
transformation of trailing nulls to newlines shown in the changelog. They are 
still distinct and separated by nulls.

>And what would happen if the function was refactored removing the pr_cont
>uses like the below: (basically, any output that uses a mechanism that
>aggregates a buffer then emits it, and there are a _lot_ of those)
>
>	printk("%s\n", buffer);

There are certainly printks which can't be trivially monitored using the printk 
format alone, but the vast majority of the ones that are monitored _do_ have 
meaningful formats and can be monitored over time. No solution to this is going 
to catch every single case, especially when so much of the information can be 
generated dyamically, but this patchset still goes a long way to making printk 
monitoring more tractable for use cases like the one described in the 
changelog.