linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	syzbot <syzbot+f4f1e871965064ae689e@syzkaller.appspotmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	asierra@xes-inc.com, ext-kimmo.rautkoski@vaisala.com,
	Jiri Slaby <jslaby@suse.com>,
	kai heng feng <kai.heng.feng@canonical.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-serial <linux-serial@vger.kernel.org>,
	mika.westerberg@linux.intel.com, o.barta89@gmail.com,
	paulburton@kernel.org, sr@denx.de,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	yegorslists@googlemail.com
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out
Date: Sat, 14 Dec 2019 17:39:02 +0900	[thread overview]
Message-ID: <8b130791-d48a-6505-f3f1-d08cada23d8d@i-love.sakura.ne.jp> (raw)
In-Reply-To: <20191214075517.GA3314866@kroah.com>

On 2019/12/14 16:55, Greg KH wrote:
>>>> That suggestion got no response for two months.
>>>>
>>>>   https://lkml.kernel.org/r/3e4e2b6b-7828-54ab-cf28-db1a396d7e20@i-love.sakura.ne.jp
>>>>
>>>> Unless we add such kernel config option to upstream kernels, it will become
>>>> a whack-a-mole game.
>>>
>>> It will be a whack-a-mole game no matter what.
>>>
>>> Yes, /dev/mem/ makes no sense to fuzz.  Neither does other things (like
>>> serial port memory addresses.)
>>
>> /dev/mem makes sense to fuzz. Ditto for other things.
> 
> What?  What are you going to find if you randomly start to write to
> /dev/mem?  How are we supposed to "fix" that?
> 

When did I say "writing to random addresses" ? If you saw my suggestion, you
will find that "fuzzer will be able to test reading from random addresses,
writing to safe addresses (in order to find new lock dependency which would
otherwise be unnoticed)".

Disabling everything using kernel config option is overkill. What you are saying
is "never try to fuzz USB drivers" by excluding USB drivers from fuzz targets.
There is no need to disable whole tests. We need to exclude only stupid operations
(e.g. forever repeating SysRq-t) from fuzz targets.

>>> You just will have a list of things that you "do not fuzz as these are
>>> dangerous".  Nothing new here, any os will have that.
>>
>> The list of kernel config options will become too complicated to maintain.
>> If we can have one kernel config option, we can avoid maintaining
>> the list of kernel config options (which keeps changing over time).
> 
> Use the newly added security_locked_down() call, that gives you a great
> indication that root can cause problems for those things.
> 

No. security_locked_down() is not for fuzz kernels but for real kernels.

"enum lockdown_reason" is overkill, it just keeps fuzzers away from finding bugs.
For example, if ftrace code has bugs but ftrace_event_open() prevents from
fuzzing due to security_locked_down(LOCKDOWN_TRACEFS) ? Fuzz kernels should not
count on security_locked_down() returning errors. That is no different from
disabling everything using kernel config options.

> And it's not a config thing, it's a functionality thing within features,
> as is explicitly shown by this very thread for the serial port memory
> location.

My suggestion is not for real kernels but for fuzz kernels.


  reply	other threads:[~2019-12-14  8:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-07  6:25 BUG: unable to handle kernel NULL pointer dereference in mem_serial_out syzbot
2019-12-12 10:57 ` Greg KH
2019-12-13  9:02   ` Dmitry Vyukov
2019-12-13  9:33     ` Greg KH
2019-12-13 10:00       ` Dmitry Vyukov
2019-12-13 10:10         ` Greg KH
2019-12-13 10:39           ` Dmitry Vyukov
2019-12-13 11:26             ` Greg KH
2019-12-17 10:48               ` Dmitry Vyukov
2020-01-07 17:02                 ` Dmitry Vyukov
2019-12-13 14:31         ` Tetsuo Handa
2019-12-13 16:07           ` Greg KH
2019-12-14  0:48             ` Tetsuo Handa
2019-12-14  7:55               ` Greg KH
2019-12-14  8:39                 ` Tetsuo Handa [this message]
2019-12-14  9:09                   ` Greg KH
2019-12-14 10:28                     ` Tetsuo Handa
2019-12-14 11:25                       ` Greg KH
2019-12-18  0:55         ` Tetsuo Handa
2019-12-18  6:53           ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8b130791-d48a-6505-f3f1-d08cada23d8d@i-love.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=asierra@xes-inc.com \
    --cc=dvyukov@google.com \
    --cc=ext-kimmo.rautkoski@vaisala.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=o.barta89@gmail.com \
    --cc=paulburton@kernel.org \
    --cc=sr@denx.de \
    --cc=syzbot+f4f1e871965064ae689e@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yegorslists@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).