linux-kernel - Re: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200903181058.23247.mega@retes.hu>
Date:	Wed, 18 Mar 2009 10:58:22 +0100
From:	Gábor Melis <mega@...es.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Ingo Molnar <mingo@...e.hu>,
	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Friesen <cfriesen@...tel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order)

On Martes 17 Marzo 2009, Linus Torvalds wrote:
> On Tue, 17 Mar 2009, Gábor Melis wrote:
> > As an application developer what I'd like to have is this:
> > synchronously generated signals are delivered before asynchronously
> > generated ones.
>
> I agree that it would be nice, but quite frankly, it's simply not how
> signals work. It would be a reasonably invasive change, and you
> wouldn't really be able to rely on it anyway since most kernels don't
> work that way.

True. I won't be able to rely on this and I'll stick to the SIGUSR2 
workaround that's confirmed by Oleg.

> What you might be able to do instead is to walk signal frames
> backwards by hand. IOW, accept the fact that sometimes signals end up
> being nested, but then you could try to find the right frame by just
> looking at them.

Walking the frames is not enough, because even if the right one is 
found, I can't put a new frame on it if it's not at the top ...

> And your trick of comparing 'info->si_ip' with
> 'context->uc_mcontext->ip' is pretty good, and lets the code itself
> walk the signal frames by just depending on the fault happening
> again.

Another example. Suppose there is a stack with a mprotected guard page 
at the end. The app's stack grows into the guard page, sigsegv is 
generated, its handler would be invoked, but a pthread_kill'ed SIGUSR1 
gets delivered first. Now the SIGUSR1 handler accesses the stack and 
triggers another fault, the sigsegv handler sees that si_ip == 
uc_mcontext->ip, so it unprotects the page and puts a frame on the 
stack, arranging for a function to be called. Then the function 
deadlocks because it waits for a signal that's blocked in the SIGUSR1 
handler.

I think it would be a definite improvement to prevent all these 
headaches from occurring and deliver asynchronously generated, thread 
private signals after the synchronous ones.

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