hook SIGSEGV

hook SIGSEGV

[net.study.sea at gmail.com]

Hi all :
     I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal?

Thanks!

hook SIGSEGV

[michi1 at michaelblizek.twilightparadox.com]

Hi!

On 21:46 Sat 10 May     , net.study.sea at gmail.com wrote:
> 
> Hi all :
>      I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal?
> 
> Thanks!

Yes, you can hook SIGSEGV like a normal signal. However, I have never tried to
do so...

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com

hook SIGSEGV

[Sam Dodrill]

After you get a SIGSEGV, you are screwed. You can probably recover if you
do a lot of work, but overall it's not worth it. Also in a signal handler
you are not guaranteed malloc() will work, the kernel may not allow you to
allocate more memory. Also your signal handler for SIGSEGV will keep
getting called because the SIGSEGV keeps coming until the program exits.
Note that you are not recommended to use functions such as printf() in a
signal handler (see:
https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers).

It might be worth looking into things like libsigsegv:
http://libsigsegv.sourceforge.net/

I hope this can help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140513/5c44cbf0/attachment.html 

hook SIGSEGV

[Yann Droneaud]

Hi,

Le mardi 13 mai 2014 ? 17:29 +0200,
michi1 at michaelblizek.twilightparadox.com a ?crit :

> On 21:46 Sat 10 May     , net.study.sea at gmail.com wrote:
> > 
> > Hi all :
> >      I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal?
> > 
> > Thanks!
> 
> Yes, you can hook SIGSEGV like a normal signal. However, I have never tried to
> do so...
> 

I've played with this: in the segv signal handler, using SA_SIGINFO 
(see sigaction(3), I've retrieved the fault address and mmap() some 
anonymous memory page here, then leave the handler.
At this point the kernel will resume the process/thread where it has 
triggered the fault. And voila. The process/thread will issue again the 
previously faulty instruction and succeed.

This approach works when fault happen on a unmapped address.

But if your process/thread is trying to read some values there and
instead found a page full of 0, it might trigger more segfault.
Especially if it's using the zero as a pointer: it's going to try to 
access to page 0, which, by default, is not map'able by userspace 
process to defeat kernel NULL pointer dereference vulns.

For write access to a read only page, depending on the underlying
mapping, you will not be able to recover from the error easily: You
probably have to unmap the read-only page, map an anonymous page
instead, and don't forget to restore the content the process was
expected to find there.

I've never tried the later, nor played with multiple threads triggering
fault. So YMMV.

Regards.

-- 
Yann Droneaud
OPTEYA

hook SIGSEGV

[Kristof Provost]

On 2014-05-10 21:46:01 (+0800), net.study.sea at gmail.com <net.study.sea@gmail.com> wrote:
>      I want to know is it possible to hook SIGSEGV to restart the
>      thread which the signal is sent to,without restart the whole
>      process? And record the place where has caused this signal?
> 
Yes, as others have already pointed out, you can hook SIGSEGV like any
other signal.

You're not going to be able to save the process any more, but you can
still collect some useful information.

I've found it very useful to have a SIGSEGV (and SIGPIPE, SIGABRT,
SIGFPE, SIGILL) handler which logs a backtrace (look at 'man backtrace')
to syslog. Very useful for debugging on targets where core dumps are
impractical.

Others have also pointed out that it might no longer be safe to call
printf() or malloc() there. That's true, but usually it's OK, and if it
turns out that it wasn't ... Well, you were crashing anyway.

Regards,
Kristof

hook SIGSEGV

[Max Filippov]

On Wed, May 14, 2014 at 4:14 PM, Kristof Provost <kristof@sigsegv.be> wrote:
> On 2014-05-10 21:46:01 (+0800), net.study.sea at gmail.com <net.study.sea@gmail.com> wrote:
>>      I want to know is it possible to hook SIGSEGV to restart the
>>      thread which the signal is sent to,without restart the whole
>>      process? And record the place where has caused this signal?
>>
> Yes, as others have already pointed out, you can hook SIGSEGV like any
> other signal.
>
> You're not going to be able to save the process any more, but you can
> still collect some useful information.
>
> I've found it very useful to have a SIGSEGV (and SIGPIPE, SIGABRT,
> SIGFPE, SIGILL) handler which logs a backtrace (look at 'man backtrace')
> to syslog. Very useful for debugging on targets where core dumps are
> impractical.
>
> Others have also pointed out that it might no longer be safe to call
> printf() or malloc() there. That's true, but usually it's OK, and if it
> turns out that it wasn't ... Well, you were crashing anyway.

Well, not anyway: you still should be able to take a longjmp out of the
signal handler to a safe place.

-- 
Thanks.
-- Max