utilizzata per verificare che il segnale indicato sia valido per la
piattaforma che si sta usando (se non lo è darà errore).
-Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
-tramite la quale si specificano tutte le caratteristiche dell'azione associata
-ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
-definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
-\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
-più usato.
-
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{0.8\textwidth}
\label{fig:sig_sigaction}
\end{figure}
+Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
+tramite la quale si specificano tutte le caratteristiche dell'azione associata
+ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
+
Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
-sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
-gestore ritorna comunque la maschera dei segnali bloccati (vedi
-sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente
-l'invocazione.
+sia specificato con \var{sa\_flag} un comportamento diverso. Quando il gestore
+ritorna la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask})
+viene comunque ripristinata al valore precedente l'invocazione.
L'uso di questo campo permette ad esempio di risolvere il problema residuo
dell'implementazione di \code{sleep} mostrata in
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,
+ non deve essere usato nelle applicazioni, serve ad
+ indicare che il campo \var{sa\_restorer} contiene
+ l'indirizzo di un cosiddetto \textit{signal
+ trampoline}.\footnotemark \\
\constd{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
gestore in forma estesa usando
\var{sa\_sigaction} al posto di
\label{tab:sig_sa_flag}
\end{table}
+\footnotetext{il \itindex{signal~trampoline} \textit{signal trampoline} è il
+ codice usato per tornare da un gestore di segnali, che originariamente
+ veniva inserito nello \textit{stack}, ma i kernel recenti come misura di
+ sicurezza impediscono l'esecuzione di codice dallo stack, per cui questo
+ codice viene spostato altrove (ad esempio nella libreria del C) ed il suo
+ indirizzo viene indicato al kernel nel campo \var{sa\_restorer}.}
+
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'introduzione dei segnali \textit{real-time} (vedi
+ con l'itroduzione 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
-specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
-rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}.
-Quest'ultima è quella classica usata anche con \func{signal}, mentre la prima
-permette di usare un gestore più complesso, in grado di ricevere informazioni
-più dettagliate dal sistema, 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
+specificare rispettivamente attraverso i campi \var{sa\_sigaction} o
+\var{sa\_handler}, a seconda dell'uso o meno del flag \const{SA\_SIGINFO}. La
+forma con \var{sa\_handler} è quella classica usata anche con \func{signal},
+mentre quella con \var{sa\_sigaction} permette di usare un gestore più
+complesso, in grado di ricevere informazioni più dettagliate dal sistema
+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
cui campi indicano i diversi tipi di valori che possono essere salvati, in
maniera alternativa, all'interno della stessa.}
-Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
+Installando un gestore di tipo \var{sa\_sigaction} diventa possibile
accedere alle informazioni restituite attraverso il puntatore a questa
struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
In generale \var{si\_code} contiene, per i segnali generici, per quelli
\textit{real-time} e per tutti quelli inviati tramite da un processo con
\func{kill} o affini, le informazioni circa l'origine del segnale stesso, ad
-esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore
-viene sempre espresso come una costante,\footnote{le definizioni di tutti i
- valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili
-in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}.
-
-Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
-fornire una informazione specifica relativa alle motivazioni della ricezione
-dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL},
-\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire
-maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
-istruzione illecita o di violazione di memoria; mentre alcuni segnali di
-controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono
-altre informazioni specifiche.
+esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore di
+\var{si\_code} viene sempre espresso come una costante,\footnote{le
+ definizioni di tutti i valori possibili si trovano in
+ \file{bits/siginfo.h}.} ed i valori possibili in questo caso sono riportati
+in tab.~\ref{tab:sig_si_code_generic}.
\begin{table}[!htb]
\footnotesize
\label{tab:sig_si_code_generic}
\end{table}
+Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
+fornire una informazione specifica relativa alle motivazioni della ricezione
+dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL},
+\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire
+maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
+istruzione illecita o di violazione di memoria; mentre alcuni segnali di
+controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono
+altre informazioni specifiche.
In questo caso il valore del campo \var{si\_code} deve essere verificato nei
confronti delle diverse costanti previste per ciascuno di detti segnali; dato
\begin{table}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|p{8cm}|}
+ \begin{tabular}[c]{|l|p{10cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
\constd{SEGV\_MAPERR} & Indirizzo non mappato.\\
\constd{SEGV\_ACCERR} & Permessi non validi per l'indirizzo.\\
+ \constd{SEGV\_BNDERR} & Controllo sui limiti di accesso (via MPX) fallito
+ (dal 3.19).\\
+ \constd{SEGV\_PKUERR} & Accesso negato da una protezione della memoria,
+ vedi sez.~\ref{sec:procadv_security_misc} (dal
+ 4.6).\\
\hline
\constd{BUS\_ADRALN} & Allineamento dell'indirizzo non valido.\\
\constd{BUS\_ADRERR} & Indirizzo fisico inesistente.\\
- \constd{BUS\_OBJERR} & Errore hardware sull'indirizzo.\\
+ \constd{BUS\_OBJERR} & Errore hardware specifico sull'indirizzo.\\
+ \constd{BUS\_MCEERR\_AR}& Rilevata corruzione sulla memoria utilizzata
+ direttamente dal processo è richiesta un'azione.\\
+ \constd{BUS\_MCEERR\_AO}& Rilevata corruzione sulla memoria su memoria non
+ utilizzata direttamente dal processo, l'azione
+ è opzionale.\\
+ % https://lore.kernel.org/patchwork/patch/158250/
\hline
\constd{TRAP\_BRKPT} & Breakpoint sul processo.\\
\constd{TRAP\_TRACE} & Trappola di tracciamento del processo.\\
+ \constd{TRAP\_BRANCH} & Il processo ha preso una branch trap.\\
+ % https://stackoverflow.com/questions/45895234/what-is-process-branch-trap
+ \constd{TRAP\_HWBKPT} & Breakpoint/watchpoint hardware.\\
\hline
\constd{CLD\_EXITED} & Il figlio è uscito.\\
\constd{CLD\_KILLED} & Il figlio è stato terminato.\\
\constd{CLD\_DUMPED} & Il figlio è terminato in modo anormale.\\
\constd{CLD\_TRAPPED} & Un figlio tracciato ha raggiunto una trappola.\\
\constd{CLD\_STOPPED} & Il figlio è stato fermato.\\
- \constd{CLD\_CONTINUED}& Il figlio è ripartito.\\
+ \constd{CLD\_CONTINUED}& Il figlio è ripartito (dal 2.6.9).\\
\hline
\constd{POLL\_IN} & Disponibili dati in ingresso.\\
\constd{POLL\_OUT} & Spazio disponibile sul buffer di uscita.\\
\constd{POLL\_PRI} & Disponibili dati di alta priorità in ingresso.\\
\constd{POLL\_HUP} & Il dispositivo è stato disconnesso.\\
\hline
+ \constd{SYS\_SECCOMP}& Innescato da una regola di \func{seccomp}, vedi
+ sez.~\ref{sec:procadv_seccomp} (dal 3.5).\\
+ \hline
\end{tabular}
\caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
impostati rispettivamente dai segnali \signal{SIGILL}, \signal{SIGFPE},
- \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP} e
- \signal{SIGPOLL}/\signal{SIGIO}.}
+ \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP},
+ \signal{SIGPOLL}/\signal{SIGIO} e \signal{SIGSYS}.}
\label{tab:sig_si_code_special}
\end{table}
del codice, appesantendo inutilmente il programma. Originariamente questo
comportamento veniva ottenuto con delle macro, ma queste hanno tutta una serie
di problemi di sintassi nel passaggio degli argomenti (si veda ad esempio
-\cite{PratC}) che in questo modo possono essere evitati.
+\cite{PratC}) che in questo modo possono essere evitati.
citato un controllo ed una assegnazione) o comunque eseguire una serie di
istruzioni, l'atomicità non è più possibile.
-In questo caso, se si vuole essere sicuri di non poter essere interrotti da un
-segnale durante l'esecuzione di una sezione di codice, lo si può bloccare
-esplicitamente modificando la maschera dei segnali del processo con la
-funzione di sistema \funcd{sigprocmask}, il cui prototipo è:
+In questo caso, se si vuole essere sicuri di non poter essere interrotti da
+uno o più segnali durante l'esecuzione di una sezione di codice, li si possono
+bloccare esplicitamente modificando la maschera dei segnali del processo
+usando la funzione di sistema \funcd{sigprocmask},\footnote{in realtà quello
+ che viene usato normalmente è il \textit{wrapper} omonimo delle \acr{glibc}
+ dato che con l'introduzione dei segnali \textit{real time} nel kernel 2.2 le
+ dimensioni del tipo \type{sigset\_t} sono cambiate e la \textit{system call}
+ sottostante è diventata \funcm{rt\_sigprocmask} che richiede un quarto
+ argomento di tipo \ctyp{size\_t} per indicare questa dimensione; il
+ \textit{wrapper} maschera questi dettagli ed inoltre ignora in maniera
+ silente i tentativi di bloccare i segnali \textit{real time} impiegati per
+ la gestione dei \textit{thread} dalla \textit{Native Thread Posix Library}
+ (vedi sez.~\ref{sec:linux_ntpl}).} il cui prototipo è:
\begin{funcproto}{
\fhead{signal.h}
dell'argomento \param{how}, secondo le modalità specificate in
tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore non nullo
per \param{oldset} la maschera dei segnali corrente viene salvata a
-quell'indirizzo.
+quell'indirizzo. Se è nullo \param{set} non viene eseguito nessun cambiamento
+e si può usare la funzione per leggere la maschera corrente in \param{oldset}.
\begin{table}[htb]
\footnotesize
\label{tab:sig_procmask_how}
\end{table}
-In questo modo diventa possibile proteggere delle sezioni di codice bloccando
-l'insieme di segnali voluto per poi riabilitarli alla fine della sezione
-critica. La funzione permette di risolvere problemi come quelli mostrati in
-fig.~\ref{fig:sig_event_wrong}, proteggendo la sezione fra il controllo del
-flag e la sua cancellazione. La funzione può essere usata anche all'interno
-di un gestore, ad esempio per riabilitare la consegna del segnale che l'ha
-invocato, in questo caso però occorre ricordare che qualunque modifica alla
-maschera dei segnali viene perduta al ritorno dallo stesso.
+La funzione consente di proteggere delle sezioni di codice bloccando l'insieme
+di segnali voluto per poi riabilitarli alla fine della sezione critica e
+risolvere problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong},
+proteggendo la sezione fra il controllo del flag e la sua cancellazione. La
+funzione può essere usata anche all'interno di un gestore, ad esempio per
+riabilitare la consegna del segnale che l'ha invocato, in questo caso però
+occorre ricordare che qualunque modifica alla maschera dei segnali viene
+perduta al ritorno dallo stesso.
Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
dei casi di \textit{race condition} restano aperte alcune possibilità legate
ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
presenta neanche questa necessità.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/sleep.c}
% trattare pidfd_send_signal, aggiunta con il kernel 5.1 (vedi
% https://lwn.net/Articles/783052/) per mandare segnali a processi senza dover
% usare un PID, vedi anche https://lwn.net/Articles/773459/,
-% https://git.kernel.org/linus/3eb39f47934f
-% trattare pure pidfd_open() (vedi https://lwn.net/Articles/789023/) per
-% ottere un pid fd pollabile aggiunta con il kernel 5.3
-% man pidfd_send_signal su le versioni più recenti della man pages
-% trattare pidfd_getfd aggiunta con il kernel 5.6
-
+% https://git.kernel.org/linus/3eb39f47934f trattare pure pidfd_open() (vedi
+% https://lwn.net/Articles/789023/) per ottere un pid fd pollabile aggiunta
+% con il kernel 5.3 ed il nuovo flag PIDFD_NONBLOCK aggionto con il 5.10 (vedi
+% https://git.kernel.org/linus/4da9af0014b5), man pidfd_send_signal su le
+% versioni più recenti della man pages trattare pidfd_getfd aggiunta con il
+% kernel 5.6
% LocalWords: kernel POSIX timer shell control ctrl kill raise signal handler
projects / gapil.git / blobdiff