| 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
| ||
|
Date: Sat, 7 Nov 2009 14:43:03 -0500 From: angelo.borsotti@...il.com To: linux-kernel@...r.kernel.org Subject: Re: Re: Strange Linux behaviour with blocking syscalls and stop signals+SIGCONT I would venture to suggest a possible solution. But let's fist see what could be a reasoneable goal to achieve. Compatibility with existing applications is a must, so, solutions must not break it. Easy porting applications written for other Unixes is also a desirable feature. Being able to write correct programs that cope with stopping/ continuing is also a must. The very last (correctness) cannot be achieved with the existing API: suppose you are implementing a library, and you want to cope with stopping (i.e. make the process using the library continue properly after having been stopped). You cannot simply restart calls (the 16 ones that are interrupted by stop signals) because EINTR can be returned also when other signals have been catched. You cannot either rely on some flags set in a handler for SIGCONT because handlers might be already in place when your library functions are called (and you cannot change them since they are out of your control). A possible solution to consider is to have the kernel store the number of the signal that interrupted a call so that user code can decide the action that is most appropriate for the signal received. Since this adds to the existing API, it cannot break existing programs. People that want to port code from other Unixes can do that simply writing wrappers for the 16 syscalls that restart them when a stop signal is received. People that want to cope with stop signals in new code can restart them testing the signal that interrupted the calls (it would use a feature that is not in the POSIX standard, but it would work). -- This message was sent on behalf of angelo.borsotti@...il.com at openSubscriber.com http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/4393984.html -- 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/
Powered by blists - more mailing lists