linux-kernel - Re: Fix signalfd interaction with thread-private signals

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, 22 Jun 2007 09:30:04 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Nicholas Miell <nmiell@...cast.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Fix signalfd interaction with thread-private signals

On Thu, 2007-06-21 at 22:58 +0400, Oleg Nesterov wrote:
> 
> > No "stealing". No signalfd, no *nothing*. Just normal signal
> behaviour.
> 
> _Another_ thread could steal SIGSEGV via read(signalfd) without Ben's patch.
> This is what Ben and Davide are worried about. I think we should not worry,
> we have the same situation if this "another" thread does
> 
>         for (;;)
>                 signal(SIGSEGV, SIG_IGN);
> 
> do_sigaction() does rm_from_queue_full().

Yeah well... I wanted to have the least surprise path... that is,
without my patch, signalfd will "sometimes" steal the SIGSEGV depending
on who races to the lock first, thus causing the target thread to
re-execute the faulting instruction and taking another SIGSEGV, and
sometimes not. It's bad from both the faulting thread point of view and
the signalfd use who gets signals "sometimes" without any guarantee.

I like the current code that at least implement a precise semantic for
all thread local signals -> they are only ever delivered to that thread,
period. If you really want to do funky things from outside, you can
still do ptrace ;-)

Ben.

-
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/