linux-kernel - Re: [PATCH/RFC] signal races/bugs, losing TIF

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, 04 Jun 2007 23:09:47 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other
	woes

On Tue, 2007-06-05 at 13:22 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
> > >  - I still think there's something wrong with dequeue_signal() being
> > > potentially called with a task different than current by signalfd, since
> > > __dequeue_signal() (among others) mucks around with current regardless.
> > > I'd love to just make signalfd's read() only do anything if current ==
> > > ctx->tsk and remove the task argument from dequeue_signal... that would
> > > fix it nicely too no ?
> > 
> > There's got to be a clean solution that does not limit signalfd, no? I 
> > have no time to look at it immediately, but I can look into it in the 
> > next few days, if someone else does not do it before...
> 
> Is there a real usage to dequeuing somebody else signals with signalfd ?
> If yes, then we can do something around the lines of passing task down
> to __dequeue_signal, though I'm not too sure waht this notifier is about
> and wether it might rely on being called from within the affected task
> context...
> 
> Ben.
> 

signalfd() doesn't deliver thread-targeted signals to the wrong threads,
does it?

Hmm.

It looks like reading from a signalfd will give you either
process-global signals or the thread-specific signals that are targeted
towards the thread that originally created the signalfd (regardless of
which thread actually calls read()).

Which is weird, to say the least. Definitely needs to be noted in the
man page, which doesn't seem to exist yet.

Is there a reason why signalfd() doesn't behave like regular signals in
this regard?

-- 
Nicholas Miell <nmiell@...cast.net>

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