netdev - Re: bpfilter causes a leftover kernel process

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: <20180829182128.687a3374@jjacky.com>
Date:   Wed, 29 Aug 2018 18:21:28 +0200
From:   Olivier Brunel <jjk@...cky.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     netdev@...r.kernel.org, daniel@...earbox.net
Subject: Re: bpfilter causes a leftover kernel process

On Tue, 28 Aug 2018 22:35:38 -0700
Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:

> > Yeah, I have a similar thing happening on shutdown, except that
> > we're talking about a kernel thread here, so that process is
> > ignored by the mentionned killing spree as a result, thus leaving
> > that process running.  
> 
> it's not a kernel thread and sounds like there is a bug in your pid 1
> that is worth fixing.

Well, it sure does look like one. By which I mean that looking at
its /proc/$PID entry, one can see that it has an empty command line and
kthreadd as parent (ppid 2), which usually are only true for kernel
threads (unless I'm mistaken).

The tool I'm using to send the signals on shutdown does indeed not use
kill(-1,sig) but instead scans /proc and determines whether or not to
signal a process (thus allowing to ignore a few specific processes to
be killed later on).

Kernel threads are obviously to be skipped, and to identify them it
uses the classic method of checking whether or not it has an empty
command line. As I said, this bpfilter helper does and that's why it is
considered a kernel thread & thus not killed.

This is also what other tools do, like ps or top, which is indeed why
they also show it as a kernel thread ("[none]").

So is this way of doing this wrong? And if so, what would be a better
way to identify kernel threads?

Out of curiosity I also had a look at how systemd does things, and it
looks to me like it does the exact same thing[1], also identifying
kernel threads by their empty command line. So I would think that a
similar issue could be observed under systemd as well.

Thanks.

[1]
https://github.com/systemd/systemd/blob/master/src/core/killall.c#L44