linux-kernel - Re: [v3.13][v3.14][Regression] kthread: make kthread

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:	Mon, 17 Mar 2014 13:39:20 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Joseph Salisbury <joseph.salisbury@...onical.com>,
	penguin-kernel@...ove.SAKURA.ne.jp, rientjes@...gle.com,
	Linus Torvalds <torvalds@...ux-foundation.org>, tj@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Kernel Team <kernel-team@...ts.ubuntu.com>
Subject: Re: [v3.13][v3.14][Regression] kthread: make kthread_create()
 killable

On Mon, 17 Mar 2014 21:19:19 +0100 Oleg Nesterov <oleg@...hat.com> wrote:

> > kthread_create_on_node() thinks that SIGKILL came from the oom-killer
> > and it cheerfully returns -ENOMEM, which is incorrect if that signal
> > came from userspace.
> 
> Yes, I think it should return -EINTR.
> 
> > And I don't _think_ we prevent
> > userspace-originated signals from unblocking
> > wait_for_completion_killable()?
> 
> And we should not.
> 
> > Root cause time: it's wrong for the oom-killer to use SIGKILL.
> 
> Not sure... what else?

If we really really have to use userspace IPC in the kernel then I
suppose we could add a new signal type (SIGKERNEL?) which userspace can
neither receive nor send.

> > In fact
> > it's basically always wrong to send signals from in-kernel.
> 
> Well, SIGSEGV, SIGIO...

Those are kernel->userspace, not kernel->kernel.

We have all sorts of cross-task mechanisms available in kernel (set_bit
and wake_up would suffice here) so we don't need to use signals with
all the baggage they bring along.

We used to do a lot more kernel signalling, but quite a lot got weeded
out years ago.  The favorite failure mode was for a task to use
TASK_INTERRUPTIBLE so that a kernel-sent signal could wake it up. 
Whoops, drivers would outright fail if the calling task happened to
have SIGINT pending!

> > Signals
> > are a userspace IPC mechanism and using them in-kernel a) makes it hard
> > (or impossible) to distinguish them from userspace-originated signals
> > and b) permits userspace to produce surprising results in the kernel,
> > which I suspect is what we're seeing here.
> 
> Well, I think in this case it doesn't matter who/why sends a signal.
> The task is killed, it should react and exit asap. And kthread_create()
> can fail in any case, at least the kernel should not crash.

Well yes.  In this "bug", userspace tried to kill udev and surprise
surprise, that's what happened.  The only real kernel bug here is the
incorrect errno.  But in the real world, the kernel changed and systems
broke - we should try to unbreak them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/