RE: insecure signal handler design

From: Michael Wojcik (Michael.Wojcikat_private)
Date: Mon Jun 04 2001 - 08:44:50 PDT

  • Next message: Thomas Jespersen: "Re: Extract perl scripts from exe files"

    > From: Michal Zalewski [mailto:lcamtufat_private]
    > Sent: Thursday, May 31, 2001 7:24 AM
    
    > This signal delivery process is handled by kernel-space, and can be
    > controlled in numerous ways (signal delivery can be blocked, ignored,
    > etc), but is asynchronous, so it can be delivered anywhere - in the
    > middle of data modification or whatever...
    
    In the classic Unix implementation, one place signals can't be delivered is
    when the process is executing in kernel mode (ie. is in a system call),
    unless it's a "slow" system call (eg. I/O against a device other than local
    disk).  Signals are delivered when the process is returning from kernel mode
    to user mode and when the process is context-switched in.  That's no help in
    preventing races, though, since the process can't predict when context
    switches occur.  See Bach's _Design of the UNIX Operating System_ for more
    information.
    
    It should be safe to use objects of type "volatile sig_atomic_t" and
    Djikstra's normal-operation semaphore algorithm to implement safe locking
    around unsafe functions called from signal handlers, but I doubt it's worth
    the effort.
    
    Or a program could block all signal delivery in most places and only clear
    it during periodic "safe" moments, but again that seems like more work than
    necessary.  In most cases it's probably easier to avoid unsafe functions
    entirely in signal handlers, and have them set volatile sig_atomic_t flags
    that the program periodically checks in the course of normal operations.
    
    Michael Wojcik             michael.wojcikat_private
    MERANT
    Department of English, Miami University
    



    This archive was generated by hypermail 2b30 : Mon Jun 04 2001 - 11:01:36 PDT