Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #1089 > unrolled thread

Safe accesses of global arrays in signal handlers?

Back to article view | Back to comp.programming.threads

Contents

  Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-25 08:01 +0200
    Re: Safe accesses of global arrays in signal handlers? Nobody <nobody@nowhere.com> - 2012-09-25 12:15 +0100
      Re: Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-27 11:20 +0200
        Re: Safe accesses of global arrays in signal handlers? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-09-27 13:23 +0100
          Re: Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-28 13:25 +0200
        Re: Safe accesses of global arrays in signal handlers? Nobody <nobody@nowhere.com> - 2012-09-27 13:35 +0100
          Re: Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-28 13:48 +0200
            Re: Safe accesses of global arrays in signal handlers? Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-09-28 18:34 +0200
              Re: Safe accesses of global arrays in signal handlers? scott@slp53.sl.home (Scott Lurndal) - 2012-09-28 17:54 +0000
            Re: Safe accesses of global arrays in signal handlers? Nobody <nobody@nowhere.com> - 2012-09-28 18:26 +0100
              Re: Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-29 13:44 +0200
                Re: Safe accesses of global arrays in signal handlers? Nobody <nobody@nowhere.com> - 2012-09-29 20:37 +0100
                  Re: Safe accesses of global arrays in signal handlers? William Ahern <william@wilbur.25thandClement.com> - 2012-09-29 17:31 -0700
                    Signal handlers writing into pipes Markus Elfring <Markus.Elfring@web.de> - 2012-09-30 13:21 +0200
                    Re: Safe accesses of global arrays in signal handlers? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-10-01 18:04 +0100
                      Signal handlers writing into pipes Markus Elfring <Markus.Elfring@web.de> - 2012-10-03 16:36 +0200
                        Re: Signal handlers writing into pipes Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-10-03 17:07 +0100
                  Re: Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-30 13:12 +0200
                    Re: Safe accesses of global arrays in signal handlers? Nobody <nobody@nowhere.com> - 2012-09-30 20:46 +0100
          Re: Safe accesses of global arrays in signal handlers? Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2012-09-28 13:39 +0100
          Re: Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-29 13:15 +0200
            Re: Safe accesses of global arrays in signal handlers? William Ahern <william@wilbur.25thandClement.com> - 2012-09-29 17:42 -0700
              Re: Safe accesses of global arrays in signal handlers? Markus Elfring <Markus.Elfring@web.de> - 2012-09-30 14:04 +0200
    Re: Safe accesses of global arrays in signal handlers? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-09-25 13:27 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1118

> Doing anything substantial in a signal handler is problematic.

Do you see difficulties from read/write accesses on global/shared arrays there?
Are atomic adjustments eventually needed for such a data type?
Is the handling of atomicity relevant here?

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#1123

Markus Elfring <Markus.Elfring@web.de> wrote:
> > Doing anything substantial in a signal handler is problematic.

> Do you see difficulties from read/write accesses on global/shared arrays there?
> Are atomic adjustments eventually needed for such a data type?
> Is the handling of atomicity relevant here?

What do you mean by shared? For example, assigning to an element of a file
scoped array like this should be fine:

	volatile sig_atomic_t foo[NSIG];

	void handler(int signo) {
		foo[signo] = 1;
	}

But what then? How do you process that? Other code can't simply scan the
array and, e.g., reset foo[SIGHUP] back to 0, unless it doesn't care about
missing any SIGHUP signals between reading and resetting the value.

You could have two arrays, with the signal handler producer and the signal
handler consumer each incrementing their own array. But you have to mask out
signals in your signal handler, because signals can interrupt signal
handlers, too.

These tricks aren't really needed anymore. On just about every platform
where you have to worry about these things, you have specialized interfaces
like kqueue, signalfd, sigtimedwait, pselect, et al which allow you to
synchronously query signal notifications.

[toc] | [prev] | [next] | [standalone]

#1126

> What do you mean by shared?

A global variable as the one that is used in your small source code example.
(Its data will be reused by other functions after it was eventually set by a
signal handler.)


> For example, assigning to an element of a file scoped array like this should be fine:

I have got doubts here.
https://www.securecoding.cert.org/confluence/display/seccode/SIG31-C.+Do+not+access+or+modify+shared+objects+in+signal+handlers


> 	volatile sig_atomic_t foo[NSIG];
> 
> 	void handler(int signo) {
> 		foo[signo] = 1;
> 	}

The access for a specific single integer can be performed atomically. Does this
situation change when the shown index is involved?
Do C/C++ compilers deal with pointer arithmetic in this use case which might
result in a portability issue?
Do any implementations or software platforms exist which guarantee that the
property "async-signal-safety" will be maintained here?

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#1091

Markus Elfring <Markus.Elfring@web.de> writes:
> A secure programming guideline contains the following information.
>
> https://www.securecoding.cert.org/confluence/display/seccode/SIG31-C.+Do+not+access+or+modify+shared+objects+in+signal+handlers
> :
> 'Accessing or modifying shared objects in signal handlers can result in race
> conditions that can leave data in an inconsistent state. The exception to this
> rule is the ability to read and write to variables of volatile sig_atomic_t.
> ...
> It is important to note that the behavior of a program that accesses an object
> of any other type from a signal handler is undefined.'

... by any/ most applicable C standards. 'For security' it is
recommended that all programs are written in strictly conforming ISO
C. Since this means they usually won't do anything useful, nobody will
ever run them and everybody is perfectly 'secure'.

Prior to C11 (as far as I have heard) atomicity (or lack thereof) of
memory accesses is a feature of the target platform and the usual way
to determine what kind of memory accesses are or aren't atomic would
be to consult the applicable documentation. Which is not 'a C
standard' but some kind of ABI document.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.programming.threads

csiph-web