From 8ef50c43a245c37e5018ecd1c3795cea0849b8cd Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 15 Aug 2021 16:46:10 +0200 Subject: [PATCH] Aggiornati elenchi signal safe functions --- signal.tex | 105 ++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 80 insertions(+), 25 deletions(-) diff --git a/signal.tex b/signal.tex index 2c8661e..c2446f1 100644 --- a/signal.tex +++ b/signal.tex @@ -2126,7 +2126,7 @@ tab.~\ref{tab:sig_sa_flag}. call} quando vengono interrotte dal suddetto segnale, riproduce cioè il comportamento standard di BSD.\\ - \constd{SA\_RESTORER} & Ad uso delle implementazioni delle liberie del C, + \constd{SA\_RESTORER} & Ad uso delle implementazioni delle librerie del C, non deve essere usato nelle applicazioni, serve ad indicare che il campo \var{sa\_restorer} contiene l'indirizzo di un cosiddetto \textit{signal @@ -2151,7 +2151,7 @@ tab.~\ref{tab:sig_sa_flag}. Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x - con l'itroduzione dei segnali \textit{real-time} (vedi + con l'introduzione dei segnali \textit{real-time} (vedi sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune informazioni addizionali usando \var{sa\_handler} con un secondo parametro addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da @@ -2164,7 +2164,7 @@ attraverso la struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in maniera alternativa, in certe implementazioni questi campi vengono addirittura definiti come una \direct{union}.\footnote{la direttiva \direct{union} del - linguaggio C definisce una variabile complessa, analoga a una stuttura, i + linguaggio C definisce una variabile complessa, analoga a una struttura, i cui campi indicano i diversi tipi di valori che possono essere salvati, in maniera alternativa, all'interno della stessa.} @@ -2593,29 +2593,22 @@ principale, cosa che ad esempio può rendere problematico chiamare all'interno di un gestore di segnali la stessa funzione che dal segnale è stata interrotta. +Ad esempio se consideriamo le funzioni dell'I/O standard di +sez.~\ref{sec:files_std_interface} è chiaro che essendo basate sull'uso da +parte delle librerie del C di buffer e puntatori interni, che possono essere +stati aggiornati in maniera parziale alla ricezione di un segnale, questi +possono trovarsi, quando riutilizzate all'interno di un gestore, in uno stato +completamente inconsistente. + \index{funzioni!\textit{signal safe}|(} -Il concetto è comunque più generale e porta ad una distinzione fra quelle che +Il concetto è comunque generale e porta ad una distinzione fra quelle che POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e -\textsl{funzioni sicure} (o più precisamente \textit{signal safe function}). -Quando un segnale interrompe una funzione insicura ed il gestore chiama al suo -interno una funzione insicura il sistema può dare luogo ad un comportamento -indefinito, la cosa non avviene invece per le funzioni sicure. - -Tutto questo significa che la funzione che si usa come gestore di segnale deve -essere programmata con molta cura per evirare questa evenienza e che non è -possibile utilizzare al suo interno una qualunque funzione di sistema, se si -vogliono evitare questi problemi si può ricorrere soltanto all'uso delle -funzioni considerate sicure. - -L'elenco delle funzioni considerate sicure varia a seconda della -implementazione utilizzata e dello standard a cui si fa riferimento. Non è -riportata una lista specifica delle funzioni sicure per Linux, e si suppone -pertanto che siano quelle richieste dallo standard. Secondo quanto richiesto -dallo standard POSIX 1003.1 nella revisione del 2003, le ``\textit{signal safe - function}'' che possono essere chiamate anche all'interno di un gestore di -segnali sono tutte quelle della lista riportata in -fig.~\ref{fig:sig_safe_functions}. +\textsl{funzioni sicure} (o più precisamente \textit{signal safe function} o +funzioni \textit{async-signal-safe}). Quando un segnale interrompe una +funzione insicura ed il gestore chiama al suo interno una funzione insicura il +sistema può dare luogo ad un comportamento indefinito, la cosa non avviene +invece per le funzioni sicure. \begin{figure}[!htb] \footnotesize \centering @@ -2656,7 +2649,27 @@ fig.~\ref{fig:sig_safe_functions}. \label{fig:sig_safe_functions} \end{figure} -\index{funzioni!\textit{signal safe}|)} +Tutto questo significa che la funzione che si usa come gestore di segnale deve +essere programmata con molta cura per evirare questa evenienza e che non è +possibile utilizzare al suo interno una qualunque funzione di sistema o di +libreria. Oltre ovviamente ad essere rientrante rispetto all'uso di eventuali +variabili globali del programma se si vogliono evitare questi problemi +all'interno di un gestore di segnali si dovrà ricorrere soltanto all'uso delle +funzioni considerate sicure.\footnote{in realtà sarebbe possibile adottare + come approccio alternativo quello di bloccare i segnali nel programma + principale tutte le volte che questo chiama funzioni insicure o utilizza + dati globali utilizzati anche dal gestore di segnali per poi riabilitarli + una volta finito; la complessità di questo approccio lo rende però + sostanzialmente impraticabile, ed effettivamente non impraticato.} + +L'elenco delle funzioni considerate sicure varia a seconda della +implementazione utilizzata e dello standard a cui si fa riferimento. Non è +riportata una lista specifica delle funzioni di sistema sicure per Linux, e si +suppone pertanto che siano quelle richieste dallo standard. Secondo quanto +richiesto dallo standard POSIX 1003.1 nella revisione del 2003, le +``\textit{signal safe function}'' che possono essere chiamate anche +all'interno di un gestore di segnali sono tutte quelle della lista riportata +in fig.~\ref{fig:sig_safe_functions}. Lo standard POSIX.1-2004 modifica la lista di fig.~\ref{fig:sig_safe_functions} aggiungendo le funzioni \func{\_Exit} e @@ -2678,6 +2691,45 @@ ulteriori funzioni in fig.~\ref{fig:sig_safe_functions_posix_2008}. \label{fig:sig_safe_functions_posix_2008} \end{figure} +Nella successiva revisione di POSIX.1-2013 sono poi state aggiunte le +ulteriori funzioni \func{fchdir}, \func{pthread\_kill}, \func{pthread\_self}, +\func{pthread\_sigmask}. L'ultima revisione dello standard alla data della +scrittura di questa sezione è la POSIX.1-2016,\footnote{un elenco è comunque + ottenibile dalla documentazione di sistema, accessibile con \texttt{man + signal-safety}, da cui si sono estratti questi elenchi.} che ha aggiunto +alle \textit{signal safe function} le ulteriori funzioni di +fig.~\ref{fig:sig_safe_functions_posix_2016}. + + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{14cm} + \func{ffs}, \func{htonl}, \func{htons}, \func{longjmp}, \func{memccpy}, + \func{memchr}, \func{memcmp}, \func{memcpy}, \func{memmove}, \func{memset}, + \func{siglongjmp}, \func{stpcpy}, \func{stpncpy}, \func{strcat}, + \func{strchr}, \func{strcmp}, \func{strcpy}, \func{strcspn}, + \func{strlen}, \func{strncat}, \func{strncmp}, \func{strncpy}, + \func{strnlen}, \func{strpbrk}, \func{strrchr}, \func{strspn}, + \func{strstr}, \func{strtok\_r}, \func{wcpcpy}, \func{wcpncpy}, + \func{wcscat}, \func{wcschr}, \func{wcscmp}, \func{wcscpy}, + \func{wcscspn}, \func{wcslen}, \func{wcsncat}, \func{wcsncmp}, + \func{wcsncpy}, \func{wcsnlen}, \func{wcspbrk}, \func{wcsrchr}, + \func{wcsspn}, \func{wcsstr}, \func{wcstok}, \func{wmemchr}, + \func{wmemcmp}, \func{wmemcpy}, \func{wmemmove}, \func{wmemset}. + \end{minipage} + \normalsize + \caption{Ulteriori funzioni sicure secondo lo standard POSIX.1-2016.} + \label{fig:sig_safe_functions_posix_2016} +\end{figure} + +Rispetto a questi elenchi occorre precisare che prima della versione 2.24 +delle \acr{glibc} l'implementazione delle funzioni \fork{execl} ed +\fork{execle} non era sicura, e che tuttora non lo è quella di +\func{aio\_suspend}. Inoltre è da evitare \func{fork}, che potrebbe essere +rimossa in future revisioni dello standard, e che già POSIX-1.2003 indicava +come tale se usata in concorrenza con \func{pthread\_atfork}. + +\index{funzioni!\textit{signal safe}|)} Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni effettuate all'interno di un gestore di segnali, qualora si debbano compiere @@ -3948,10 +4000,13 @@ tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}. % LocalWords: epoch multiplexing overrun res lpthread sec nsec curr one shot % LocalWords: delete stopped gdb alpha mips emulation locking ppoll epoll PGID % LocalWords: pwait msgrcv msgsnd semop semtimedop runnable sigisemptyset HRT -% LocalWords: sigorset sigandset BOOTTIME Android request remain +% LocalWords: sigorset sigandset BOOTTIME Android request remain cap dell' %%% Local Variables: %%% mode: latex %%% TeX-master: "gapil" %%% End: +% LocalWords: IPC dest left right trampoline BNDERR MPX PKUERR MCEERR async +% LocalWords: BRANCH branch HWBKPT watchpoint SECCOMP seccomp wrapper pidfd +% LocalWords: fchdir sigmask safety -- 2.30.2