netdev - Re: [PATCHSET] printk, netconsole: implement reliable netconsole

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]

Message-Id: <201504182209.FDC13506.FHFVOOQMJLFtSO@I-love.SAKURA.ne.jp>
Date:	Sat, 18 Apr 2015 22:09:35 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	tj@...nel.org
Cc:	davem@...emloft.net, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCHSET] printk, netconsole: implement reliable netconsole

Tejun Heo wrote:
> > If we can assume that scheduler is working, adding a kernel thread that
> > does
> > 
> >   while (1) {
> >       read messages with metadata from /dev/kmsg
> >       send them using UDP network
> >   }
> > 
> > might be easier than modifying netconsole module.
> 
> But, I mean, if we are gonna do that in kernel, we better do it
> properly where it belongs.  What's up with "easier than modifying
> netconsole module"?  Why is netconsole special?  And how would the
> above be any less complex than a single timer function?  What am I
> missing?

User space daemon is sometimes disturbed unexpectedly due to

  (a) SIGKILL by OOM-killer
  (b) spurious ptrace() by somebody
  (c) spurious signals such as SIGSTOP / SIGINT
  (d) stalls triggered by page faults under OOM condition
  (e) other problems such as scheduler being not working

We have built-in protection for (a) named /proc/$pid/oom_score_adj , but
we need to configure access control modules for protecting (b) and (c),
and we don't have protection for (d). Thinking from OOM stall discussion,
(d) is fatal when trying to obtain kernel messages under problematic
condition. I thought that a kernel thread that does

  while (1) {
      read messages with metadata from /dev/kmsg
      send them using UDP network
  }

is automatically protected from (a), (b), (c) and (d), and it could be
implemented outside of netconsole module.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html