Skip to content
Snippets Groups Projects
Select Git revision
1 result Searching

fcntl.c

Blame
    • Eric W. Biederman's avatar
      d08477aa
      fcntl: Don't use ambiguous SIG_POLL si_codes · d08477aa
      Eric W. Biederman authored
      
      We have a weird and problematic intersection of features that when
      they all come together result in ambiguous siginfo values, that
      we can not support properly.
      
      - Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.
      
      - Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
        that imply they are signal specific si_codes and using the
        aforementioned arbitrary signal to deliver them.
      
      - Supporting injection of arbitrary siginfo values for debugging and
        checkpoint/restore.
      
      The result is that just looking at siginfo si_codes of 1 to 6 are
      ambigious.  It could either be a signal specific si_code or it could
      be a generic si_code.
      
      For most of the kernel this is a non-issue but for sending signals
      with siginfo it is impossible to play back the kernel signals and
      get the same result.
      
      Strictly speaking when the si_code was changed from SI_SIGIO to
      POLL_IN and friends between 2.2 and 2.4 this functionality was not
      ambiguous, as only real time signals were supported.  Before 2.4 was
      released the kernel began supporting siginfo with non realtime signals
      so they could give details of why the signal was sent.
      
      The result is that if F_SETSIG is set to one of the signals with signal
      specific si_codes then user space can not know why the signal was sent.
      
      I grepped through a bunch of userspace programs using debian code
      search to get a feel for how often people choose a signal that results
      in an ambiguous si_code.  I only found one program doing so and it was
      using SIGCHLD to test the F_SETSIG functionality, and did not appear
      to be a real world usage.
      
      Therefore the ambiguity does not appears to be a real world problem in
      practice.  Remove the ambiguity while introducing the smallest chance
      of breakage by changing the si_code to SI_SIGIO when signals with
      signal specific si_codes are targeted.
      
      Fixes: v2.3.40 -- Added support for queueing non-rt signals
      Fixes: v2.3.21 -- Changed the si_code from SI_SIGIO
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      d08477aa
      History
      fcntl: Don't use ambiguous SIG_POLL si_codes
      Eric W. Biederman authored
      
      We have a weird and problematic intersection of features that when
      they all come together result in ambiguous siginfo values, that
      we can not support properly.
      
      - Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.
      
      - Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
        that imply they are signal specific si_codes and using the
        aforementioned arbitrary signal to deliver them.
      
      - Supporting injection of arbitrary siginfo values for debugging and
        checkpoint/restore.
      
      The result is that just looking at siginfo si_codes of 1 to 6 are
      ambigious.  It could either be a signal specific si_code or it could
      be a generic si_code.
      
      For most of the kernel this is a non-issue but for sending signals
      with siginfo it is impossible to play back the kernel signals and
      get the same result.
      
      Strictly speaking when the si_code was changed from SI_SIGIO to
      POLL_IN and friends between 2.2 and 2.4 this functionality was not
      ambiguous, as only real time signals were supported.  Before 2.4 was
      released the kernel began supporting siginfo with non realtime signals
      so they could give details of why the signal was sent.
      
      The result is that if F_SETSIG is set to one of the signals with signal
      specific si_codes then user space can not know why the signal was sent.
      
      I grepped through a bunch of userspace programs using debian code
      search to get a feel for how often people choose a signal that results
      in an ambiguous si_code.  I only found one program doing so and it was
      using SIGCHLD to test the F_SETSIG functionality, and did not appear
      to be a real world usage.
      
      Therefore the ambiguity does not appears to be a real world problem in
      practice.  Remove the ambiguity while introducing the smallest chance
      of breakage by changing the si_code to SI_SIGIO when signals with
      signal specific si_codes are targeted.
      
      Fixes: v2.3.40 -- Added support for queueing non-rt signals
      Fixes: v2.3.21 -- Changed the si_code from SI_SIGIO
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    alignment.c 25.42 KiB