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:   Sun, 7 Feb 2021 16:53:11 +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

Chris Down writes:
>>>3. `KERN_SOH + level' can appear in other places than just printk strings
>>>
>>>KERN_SOH is just ASCII '\001' -- it's not distinctive or unique, even when
>>>paired with a check for something that looks like a level after it. For this
>>>reason, your proposed patch results in a non-trivial amount of non-printk
>>>related garbage in its output. For example:
>>>
>>>     % binutils/strings -k /tmp/vmlinux | head -5
>>>     3L)s
>>>     3L)s
>>>     c,[]A\
>>>     c(L)c
>>>     d$pL)d$`u4
>>>
>>>Fundamentally, one cannot use a tool which just determines whether something is
>>>printable to determine semantic intent.
>>
>>$ kernel_strings --kernel --section ".rodata" vmlinux
>>
>>I got exactly 0.
>
>"It works on my computer" is not a valid testing methodology, 
>especially for something as complex as the Linux kernel. It's 
>especially not a valid rebuttal to someone demonstrating that it 
>clearly doesn't work on theirs.
>
>Even filtering to the .rodata section, there's plenty of garbage just 
>in the first five cases:
>
>    % binutils/strings --kernel --section ".rodata" /tmp/vmlinux | head -5
>    3******* Your BIOS seems to not contain a fix for K8 errata #93
>    1>pBC)
>    dTRAC
>    6Run %s as init process
>    7calling  %pS @ %i
>
>Clearly there are cases that you are not considering. My kernel config 
>is attached if you want to try and replicate, but regardless, it's 
>really not valid to say "it works for me" in response to someone 
>showing that it doesn't.

Attached.

View attachment "config" of type "text/plain" (68032 bytes)