linux-kernel - Re: Re: Strange Linux behaviour with blocking syscalls and stop signals+SIGCONT

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>] [day] [month] [year] [list]

Message-ID: <13000625.11257622983772.JavaMail.root@wombat>
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/