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:   Fri, 5 Feb 2021 22:45:19 +0000
From:   Chris Down <chris@...isdown.name>
To:     Steven Rostedt <rostedt@...dmis.org>
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,
        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

Hi Steven,

Steven Rostedt writes:
>Interesting, because when I was looking at the original patch (looked at
>the lore link before reading your reply), I thought to myself "this looks
>exactly like what I did for trace_printk formats", which the above file is
>where it is shown. I'm curious if this work was inspired by that?

The double __builtin_constant_p() trick was suggested by Johannes based on 
prior art in trace_puts() just prior to patch submission. Other than that, it 
seems we came up with basically the same solution independently. :-)

>> Anyway, there is something wrong at the moment. The output looks fine
>> with cat. But "less" says that it is a binary format and the output
>> is a bit messy:
>
>Hmm, that's usually the case when lseek gets messed up. Not sure how that
>happened.

It looks as intended to me -- none of the newlines, nulls, or other control 
sequences are escaped currently, since I didn't immediately see a reason to do 
that. If that's a blocker though, I'm happy to change it.

>> $> less /proc/printk_formats
>> "/proc/printk_formats" may be a binary file.  See it anyway?
>> vmlinux,^A3Warning: unable to open an initial console.
>> ^@...inux,^A3Failed to execute %s (error %d)
>> ^@...inux,^A6Kernel memory protection disabled.
>> ^@...inux,^A3Starting init: %s exists but couldn't execute it (error %d)
>>
>>
>> That is for now. I still have to think about it. And I am also curious
>> about what others thing about this idea.
>>
>
>I'm not against the idea. I don't think it belongs in /proc. Perhaps
>debugfs is a better place to put it.

Any location is fine with me, as long as it gets to userspace. How does 
<debugfs>/printk/formats or <debugfs>/printk/formats/<module> sound to you?

Thanks,

Chris