Charles-François Natali added the comment:

>> You can't use longjmp from signal handlers. Well, you can, but 99% of the 
>> code that does it is broken, because you can only call async-safe functions 
>> from within a signal handler, and certainly can't run the intepreter.
>
> I don't see the reason to run the interpreter. But a quick look at the source 
> shows that the current implementation already uses longjmps to handle SIGFPE 
> (see pyfpe.h and fpectlmodule.c). It seems to be in use on many platforms.
>
> The only problem I see so far is the possibility that we have to protect too 
> much. However, as I could guess from quickly browsing through the mmap() 
> implementation, the address of the mmap()ed region never leaves the module, 
> all accesses are done using exported methods. If it is really the case, we 
> can wrap them into something similar to PyFPE_START_PROTECT() and 
> PyFPE_END_PROTECT() (see comments in pyfpe.h).

SIGFPE is not handled by default (it's not generated by default, you
get NaN and friends).
I don't think there a re many uses of the fpe module, because it's
inherently unsafe.

For example, in our case, let's say you want to protect mmap_item():
what do you in case of SIGBUS?
Use longjmp to jump out of the signal handler and raise an exception?
That won't work, because you'll still be running on behalf of the
signal handler, so as soon as you call a non async safe function (or
non reentrant code), you'll deadlock, crash, or suffer from all the
consequences of undefined behavior, which is much more dangerous than
crashing on a SIGBUS.

The *only* thing you can do is exit.

Please have a look at this:
https://www.securecoding.cert.org/confluence/display/seccode/SIG35-C.+Do+not+return+from+SIGSEGV,+SIGILL,+or+SIGFPE+signal+handlers
https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler

> A pity Posix isn't smart enough to refuse truncate()ing when there's a mmap 
> open on the affected pages. Python 3's buffer API is superior in that respect 
> :-)

Yes, but Python only cares about the current process.
Here the exact same problem occurs if the file is truncated by another
process: performing such checks for all the processes would be awfuly
expensive (and probably impossible in a race-free way).
Also, it's probably impossible to do on e.g. NFS mmaped files (the
server is stateless).

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16212>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to