linux-kernel - Re: [PATCH v2] twist: allow converting pr_devel()/pr

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, 29 May 2020 09:07:32 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into
 snprintf()

On 2020/05/29 4:50, Linus Torvalds wrote:
> On Thu, May 28, 2020 at 8:17 AM Tetsuo Handa
> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>>
>> CONFIG_TWIST_FOR_SYZKALLER_TESTING is meant for linux-next only.
>> But CONFIG_TWIST_KERNEL_BEHAVIOR is meant for Linus's tree.
> 
> I really absolutely still detest this all. I don't see the point. The
> naming is completely random (both "twist" and then options like
> "TWIST_FOR_SYZKALLER_TESTING" that have no conceptual meaning.

Oh, I made copy&paste error. I wanted to say

  CONFIG_TWIST_KERNEL_BEHAVIOR and CONFIG_TWIST_FOR_SYZKALLER_TESTING are
  meant for Linus's tree.

  CONFIG_DEBUG_AID_FOR_SYZBOT is meant for linux-next only, and will be
  removed after CONFIG_TWIST_FOR_SYZKALLER_TESTING went to Linus's tree.

If you don't like the name "CONFIG_TWIST_FOR_SYZKALLER_TESTING", I'm happy
to rename it.

> 
> I still don't understand why this small set of random options couldn't
> just be kernel options that get set on the command line, and that have
> independent and sane and explainable behavior?

You mean "export these behavior as kernel command line options"? That will
involve run-time costs (while build-time branching based on #ifdef can
completely eliminate run-time costs). Also, as number of options which
can be controlled at boot-time grows, the kernel command line will become
too long to specify all of these behavior. Also, making these options
controllable at boot-time involves making these options as user-visible ABI
(which is bad, for the twists which we want might change in the future).

> Why this odd mentality of "syzkaller is special"?

Why do you think "syzkaller is special" ? There is no syzkaller-specific
choice. CONFIG_TWIST_FOR_SYZKALLER_TESTING is intended for eliminating the
need of managing CONFIG_TWIST_* options on each kernel tree/commit. When
a different fuzzer (or some kernel testing project) appears, they can define
their own CONFIG_TWIST_FOR_$projectname_TESTING as well.

> 
> I've complained about this whole thing before. I'm getting really fed
> up with this whole concept of "magic crazy config options".
> 
> The kernel configuration phase is just about the _worst_ part of the
> kernel, we shouldn't make these pointless things make it even worse.

Current kernel is not well segmented enough to allow switching based on
per process flags. We can't distinguish whether some kernel message was
caused by a process with such flags.

All we could afford is to switch based on kernel boot command line. But
that will entail a lot of code/data (and runtime-cost) which is not used
if the administrator does not turn on the switches.

After all, switching at the kernel configuration phase is the most simple
approach.

On 2020/05/29 5:01, Linus Torvalds wrote:
> On Thu, May 28, 2020 at 12:50 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> I still don't understand why this small set of random options couldn't
>> just be kernel options that get set on the command line, and that have
>> independent and sane and explainable behavior? Why this odd mentality
>> of "syzkaller is special"?
> 
> And just to clarify: the kernel option wouldn't be "syzcaller_twist"
> or something insane like that.
> 
> It would be something like "kbd-disable-hotkeys" or whatever: actual
> real text that says what it does.

If you don't like the name "CONFIG_TWIST_FOR_SYZKALLER_TESTING", please
suggest an example name you would accept. But if you don't like switching
based on the kernel configuration options, I can't find a better solution.