Ancora revisione capitolo funzionalità di sistema
authorSimone Piccardi <piccardi@truelite.it>
Fri, 4 Oct 2019 14:56:05 +0000 (16:56 +0200)
committerSimone Piccardi <piccardi@truelite.it>
Fri, 4 Oct 2019 14:56:05 +0000 (16:56 +0200)
listati/timex.h
procadv.tex
system.tex

index 022ccde..9d0b1bf 100644 (file)
@@ -10,4 +10,5 @@ struct timex {
     long tolerance;       /* clock frequency tolerance (ppm) (read only) */
     struct timeval time;  /* (read only) */
     long tick;            /* (modified) usecs between clock ticks */
+    ...
 };
index 7602fe5..2eac844 100644 (file)
@@ -463,7 +463,8 @@ opportuno dettagliare maggiormente.
                               sez.~\ref{sec:file_ownership_management}).\\
     \constd{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
                                permessi di lettura, scrittura ed esecuzione dei
-                               file, (vedi sez.~\ref{sec:file_access_control}).\\ 
+                               file, (vedi
+                                 sez.~\ref{sec:file_access_control}).\\
     \constd{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
                               permessi di lettura ed esecuzione per
                               le directory (vedi
@@ -1484,12 +1485,25 @@ alcune opzioni di controllo attivabili via \func{sysctl} o il filesystem
 
 
 % TODO: trattare keyctl (man 2 keyctl)
-
+% (fare sezione dedicata ????)
+% TODO documentare la Crypto API del kernel
 
 
 % TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
 % pkey_mprotect, introdotte con il kernel 4.8, vedi
-% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt 
+% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
+
+% TODO documentare la syscall getrandom, introdotta con il kernel 3.17, vedi
+% http://lwn.net/Articles/606141/, ed introdotta con le glibc solo con la
+% versione 2.25, vedi https://lwn.net/Articles/711013/
+
+%\subsection{La gestione delle chiavi crittografiche}
+%\label{sec:keyctl_management}
+
+% TODO non è chiaro se farlo qui, ma documentare la syscall bpf aggiunta con il
+% kernel 3.18, vedi http://lwn.net/Articles/612878/; al riguardo vedi anche
+% https://lwn.net/Articles/660331/ 
+
 
 \section{Funzioni di gestione e controllo}
 \label{sec:proc_manage_control}
index 84dad32..27f1f38 100644 (file)
@@ -1158,7 +1158,7 @@ argomenti aggiuntivi, i rispettivi prototipi sono:
 
 Le funzioni si comportano esattamente come le precedenti analoghe non
 rientranti, solo che restituiscono il risultato all'indirizzo specificato dal
-primo argomento aggiuntivo \param{buffer} mentre il secondo, \param{result)}
+primo argomento aggiuntivo \param{buffer} mentre il secondo, \param{result},
 viene usato per restituire il puntatore al buffer stesso.
 
 Infine la \acr{glibc} fornisce altre due funzioni, \funcd{updwtmp} e
@@ -1282,15 +1282,16 @@ illustra i comandi attualmente disponibili:
 \item[\constd{LINUX\_REBOOT\_CMD\_RESTART2}] Viene inviato sulla console il
   messaggio ``\textit{Restarting system with command '\%s'.}'' ed avviata
   immediatamente la procedura di riavvio usando il comando fornito
-  nell'argomento \param{arg} che viene stampato al posto di \textit{'\%s'}
+  nell'argomento \param{arg} che viene stampato al posto di \texttt{'\%s'}
   (veniva usato per lanciare un altro programma al posto di \cmd{init}). Nelle
   versioni recenti questo argomento viene ignorato ed il riavvio può essere
   controllato dall'argomento di avvio del kernel \texttt{reboot=...}  Se non
   si è eseguita una sincronizzazione dei dati su disco con \func{sync} questi
   saranno perduti.
+  % TODO: trattare LINUX_REBOOT_CMD_SW_SUSPEND
+  % TODO: rimandare agli effetti di reboot sui namespace
 \end{basedescript}
 
-
 Come appena illustrato usando il comando \const{LINUX\_REBOOT\_CMD\_KEXEC} si
 può eseguire un riavvio immediato pre-caricando una immagine del kernel, che
 verrà eseguita direttamente. Questo meccanismo consente di evitare la
@@ -1364,14 +1365,14 @@ che sia effettivamente eseguibile sul proprio processore.
     \hline
     \constd{KEXEC\_ON\_CRASH}        & Il kernel caricato sarà eseguito
                                       automaticamente in caso di crollo del
-                                      sistema.\\
+                                      sistema (dal kernel 2.6.13).\\
     \constd{KEXEC\_PRESERVE\_CONTEXT}& Viene preservato lo stato dei programmi 
                                       e dei dispositivi prima dell'esecuzione
                                       del nuovo kernel. Viene usato
                                       principalmente per l'ibernazione del
                                       sistema ed ha senso solo se si è
                                       indicato un numero di segmento maggiore
-                                      di zero.\\
+                                      di zero (dal kernel 2.6.27).\\
     \hline
     \constd{KEXEC\_ARCH\_DEFAULT}    & Il kernel caricato verrà eseguito nella
                                       architettura corrente. \\
@@ -1401,30 +1402,14 @@ più in grado di essere eseguito in maniera coerente.  Il secondo valore,
 programmi e dei dispositivi, e viene in genere usato per realizzare la
 cosiddetta ibernazione in RAM.
 
-% TODO: introdotta con il kernel 3.17 è stata introdotta
-% kexec_file_load, per caricare immagine firmate per il secure boot,
-% vedi anche http://lwn.net/Articles/603116/
-
-% TODO documentare keyctl ????
-% (fare sezione dedicata ????)
-
-% TODO documentare la Crypto API del kernel
-
-% TODO documentare la syscall getrandom, introdotta con il kernel 3.17, vedi
-% http://lwn.net/Articles/606141/, ed introdotta con le glibc solo con la
-% versione 2.25, vedi https://lwn.net/Articles/711013/
+% TODO: con il kernel 3.17 è stata introdotta kexec_file_load, per caricare
+% immagine firmate per il secure boot, vedi anche
+% http://lwn.net/Articles/603116/
 
-%\subsection{La gestione delle chiavi crittografiche}
-%\label{sec:keyctl_management}
-
-%TODO non è chiaro se farlo qui, ma documentare la syscall bpf aggiunta con il
-% kernel 3.18, vedi http://lwn.net/Articles/612878/; al riguardo vedi anche
-% https://lwn.net/Articles/660331/ 
 
 \section{Il controllo dell'uso delle risorse}
 \label{sec:sys_res_limits}
 
-
 Dopo aver esaminato in sez.~\ref{sec:sys_management} le funzioni che
 permettono di controllare le varie caratteristiche, capacità e limiti del
 sistema a livello globale, in questa sezione tratteremo le varie funzioni che
@@ -1540,7 +1525,7 @@ sez.~\ref{sec:sys_unix_time}). I campi \var{ru\_minflt} e \var{ru\_majflt}
 servono a quantificare l'uso della memoria virtuale e corrispondono
 rispettivamente al numero di \textit{page fault} (vedi
 sez.~\ref{sec:proc_mem_gen}) avvenuti senza richiedere I/O su disco (i
-cosiddetti \textit{minor page fault}), a quelli che invece han richiesto I/O
+cosiddetti \textit{minor page fault}), a quelli che invece han richiesto I/O
 su disco (detti invece \textit{major page
   fault}).% mentre \var{ru\_nswap} ed al numero di volte che
 % il processo è stato completamente tolto dalla memoria per essere inserito
@@ -1642,13 +1627,13 @@ limite corrente e limite massimo.
   \label{fig:sys_rlimit_struct}
 \end{figure}
 
-Come accennato processo ordinario può alzare il proprio limite corrente fino
-al valore del limite massimo, può anche ridurre, irreversibilmente, il valore
-di quest'ultimo.  Nello specificare un limite, oltre a fornire dei valori
-specifici, si può anche usare la costante \const{RLIM\_INFINITY} che permette
-di sbloccare completamente l'uso di una risorsa. Si ricordi però che solo un
-processo con i privilegi di amministratore\footnote{per essere precisi in
-  questo caso quello che serve è la \textit{capability}
+Come accennato un processo ordinario può alzare il proprio limite corrente
+fino al valore del limite massimo, e può anche ridurre, irreversibilmente, il
+valore di quest'ultimo.  Nello specificare un limite, oltre a fornire dei
+valori specifici, si può anche usare la costante \const{RLIM\_INFINITY} che
+permette di sbloccare completamente l'uso di una risorsa. Si ricordi però che
+solo un processo con i privilegi di amministratore\footnote{per essere precisi
+  in questo caso quello che serve è la \textit{capability}
   \const{CAP\_SYS\_RESOURCE} (vedi sez.~\ref{sec:proc_capabilities}).} può
 innalzare un limite al di sopra del valore corrente del limite massimo ed
 usare un valore qualsiasi per entrambi i limiti.
@@ -1657,7 +1642,7 @@ Ciascuna risorsa su cui si possono applicare dei limiti è identificata da uno
 specifico valore dell'argomento \param{resource}, i valori possibili per
 questo argomento, ed il significato della risorsa corrispondente, dei
 rispettivi limiti e gli effetti causati dal superamento degli stessi sono
-riportati nel seguente elenco:
+riportati nel seguente elenco.
 
 \begin{basedescript}{\desclabelwidth{2.2cm}}%\desclabelstyle{\nextlinelabel}}
 \item[\constd{RLIMIT\_AS}] Questa risorsa indica, in byte, la dimensione
@@ -1697,8 +1682,8 @@ riportati nel seguente elenco:
   dimensione del segmento dati di un processo (vedi
   sez.~\ref{sec:proc_mem_layout}).  Il tentativo di allocare più memoria di
   quanto indicato dal limite corrente causa il fallimento della funzione di
-  allocazione eseguita (\func{brk} o \func{sbrk}) con un errore di
-  \errcode{ENOMEM}.
+  allocazione eseguita (\func{brk} o \func{sbrk} e dal kernel 4.7 anche
+  \func{mmap}) con un errore di \errcode{ENOMEM}.
 
 \item[\constd{RLIMIT\_FSIZE}] Questa risorsa indica, in byte, la massima
   dimensione di un file che un processo può usare. Se il processo cerca di
@@ -1756,6 +1741,13 @@ messaggi vuoti che comunque richiede delle risorse di gestione. Questa risorsa
   descriptor farà fallire la funzione (\func{open}, \func{dup}, \func{pipe},
   ecc.) con un errore \errcode{EMFILE}.
 
+  % TODO: aggiungere Dal 4.5 definisce anche il limite sul numero massimo di
+  % file descriptor che un processo non privilegiato (senza la capacità
+  % \const{CAP\_SYS\_RESOURCE}, vedi sez.~\ref{sec:proc_capabilities}) può
+  % avere in corso di trasmissione verso altri
+  % processi usando i socket Unix-domain (vedi sez.XXX), il limite si applica
+  % si applica a \func{sendmsg}.
+
 \item[\constd{RLIMIT\_NPROC}] Questa risorsa indica il numero massimo di
   processi che possono essere creati dallo stesso utente, che viene
   identificato con l'\ids{UID} reale (vedi sez.~\ref{sec:proc_access_id}) del
@@ -1825,12 +1817,12 @@ Si noti come le due funzioni \func{getrlimit} e \func{setrlimit} consentano di
 operare solo sul processo corrente. Per questo motivo a partire dal kernel
 2.6.36 (e dalla \acr{glibc} 2.13) è stata introdotta un'altra funzione di
 sistema \funcd{prlimit} il cui scopo è quello di estendere e sostituire le
-precedenti.  Il suo prototipo è:
+precedenti; il suo prototipo è:
 
 \begin{funcproto}{
 \fhead{sys/resource.h}
 \fdecl{int prlimit(pid\_t pid, int resource, const struct rlimit *new\_limit,\\
-\phantom{int prlimit(}struct rlimit *old\_limit}
+\phantom{int prlimit(}struct rlimit *old\_limit)}
 \fdesc{Legge e imposta i limiti di una risorsa.} 
 }
 
@@ -1849,7 +1841,7 @@ precedenti.  Il suo prototipo è:
 }
 \end{funcproto}
 
-La funzione è specifica di Linux e non portabile; per essere usata richiede
+La funzione è specifica di Linux e non portabile, per essere usata richiede
 che sia stata definita la macro \macro{\_GNU\_SOURCE}. Il primo argomento
 indica il \ids{PID} del processo di cui si vogliono cambiare i limiti e si può
 usare un valore nullo per indicare il processo chiamante.  Per modificare i
@@ -1868,6 +1860,8 @@ possibile sia leggere che scrivere, anche in contemporanea, i valori dei
 limiti. Il significato dell'argomento \param{resource} resta identico rispetto
 a \func{getrlimit} e \func{setrlimit}, così come i restanti requisiti. 
 
+% TODO: a bassa priorità, documentare i vari problemi e cambiamenti nella
+% implementazione di queste funzioni dettagliati nella pagina di manuale
 
 \subsection{Le informazioni sulle risorse di memoria e processore}
 \label{sec:sys_memory_res}
@@ -1953,8 +1947,8 @@ attivi); anche queste sono informazioni comunque ottenibili attraverso
 
 Infine la \acr{glibc} riprende da BSD la funzione \funcd{getloadavg} che
 permette di ottenere il carico di processore della macchina, in questo modo è
-possibile prendere decisioni su quando far partire eventuali nuovi processi.
-Il suo prototipo è:
+possibile prendere decisioni su quando far partire eventuali nuovi processi,
+il suo prototipo è:
 
 \begin{funcproto}{
 \fhead{stdlib.h}
@@ -2013,7 +2007,7 @@ prototipo è:
 \end{funcproto}
 
 La funzione attiva il salvataggio dei dati sul file indicato dal
-\textit{pathname} contenuti nella stringa puntata da \param{filename}; la
+\textit{pathname} contenuto nella stringa puntata da \param{filename}; la
 funzione richiede che il processo abbia i privilegi di amministratore (è
 necessaria la \textit{capability} \const{CAP\_SYS\_PACCT}, vedi
 sez.~\ref{sec:proc_capabilities}). Se si specifica il valore \val{NULL} per
@@ -2340,10 +2334,12 @@ primi 41 secondi) e se il valore del contatore eccede le dimensione del tipo
 Come anticipato in sez.~\ref{sec:sys_unix_time} il \textit{calendar time}
 viene espresso normalmente con una variabile di tipo \type{time\_t}, che
 usualmente corrisponde ad un tipo elementare; in Linux è definito come
-\ctyp{long int}, che di norma corrisponde a 32 bit. Il valore corrente del
-\textit{calendar time}, che indicheremo come \textsl{tempo di sistema}, può
-essere ottenuto con la funzione \funcd{time} che lo restituisce nel suddetto
-formato, il suo prototipo è:
+\ctyp{long int}, che di norma corrisponde a 32 bit, cosa che pone un limite al
+valore massimo esprimibile al 19 gennaio 2038, per ovviare alla cosa nelle
+versioni più recenti viene usato un valore di dimensioni maggiori. Il valore
+corrente del \textit{calendar time}, che indicheremo come \textsl{tempo di
+  sistema}, può essere ottenuto con la funzione \funcd{time} che lo
+restituisce nel suddetto formato, il suo prototipo è:
 
 \begin{funcproto}{
 \fhead{time.h}
@@ -2357,7 +2353,9 @@ formato, il suo prototipo è:
 \end{funcproto}
 
 L'argomento \param{t}, se non nullo, deve essere l'indirizzo di una variabile
-su cui duplicare il valore di ritorno.
+su cui duplicare il valore di ritorno, ma il suo uso è considerato obsoleto e
+deve essere sempre specificato come \val{NULL}, nel qual caso la funzione non
+può fallire.
 
 Analoga a \func{time} è la funzione \funcd{stime} che serve per effettuare
 l'operazione inversa, e cioè per impostare il tempo di sistema qualora questo
@@ -2381,14 +2379,15 @@ sia necessario; il suo prototipo è:
 Dato che modificare l'ora ha un impatto su tutto il sistema il cambiamento
 dell'orologio è una operazione privilegiata e questa funzione può essere usata
 solo da un processo con i privilegi di amministratore (per la precisione la
-\textit{capability} \const{CAP\_SYS\_TIME}), altrimenti la chiamata fallirà
-con un errore di \errcode{EPERM}.
+\textit{capability} \const{CAP\_SYS\_TIME}, vedi
+sez.~\ref{sec:proc_capabilities}), altrimenti la chiamata fallirà con un
+errore di \errcode{EPERM}.
 
 Data la scarsa precisione nell'uso di \type{time\_t}, che ha una risoluzione
-massima di un secondo, quando si devono effettuare operazioni sui tempi di
-norma l'uso delle due funzioni precedenti è sconsigliato, ed esse sono di
-solito sostituite da \funcd{gettimeofday} e \funcd{settimeofday},\footnote{le
-  due funzioni \func{time} e \func{stime} sono più antiche e derivano da SVr4,
+di un secondo, quando si devono effettuare operazioni sui tempi l'uso delle
+due funzioni precedenti è sconsigliato, ed esse sono di solito sostituite da
+\funcd{gettimeofday} e \funcd{settimeofday},\footnote{le due funzioni
+  \func{time} e \func{stime} sono più antiche e derivano da SVr4,
   \func{gettimeofday} e \func{settimeofday} sono state introdotte da BSD, ed
   in BSD4.3 sono indicate come sostitute delle precedenti, \func{gettimeofday}
   viene descritta anche in POSIX.1-2001.} i cui prototipi sono:
@@ -2538,9 +2537,10 @@ delle costanti elencate in tab.~\ref{tab:adjtimex_return}.
 La funzione richiede come argomento il puntatore ad una struttura di tipo
 \struct{timex}, la cui definizione, effettuata in \headfiled{sys/timex.h}, è
 riportata in fig.~\ref{fig:sys_timex_struct} per i campi che interessano la
-possibilità di essere modificati documentati anche nella pagina di manuale. In
-realtà la struttura è stata estesa con ulteriori campi, i cui valori sono
-utilizzabili solo in lettura, la cui definizione si può trovare direttamente
+possibilità di essere modificati. In realtà la struttura è stata estesa con
+ulteriori campi, i cui valori sono utilizzabili solo in lettura, non riportati
+in fig.~\ref{fig:sys_timex_struct}, i dettagli di questi campi si possono
+recuperare dalla pagina di manuale di \func{adjtimex}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2723,7 +2723,7 @@ Nel caso di \func{ctime} la funzione tiene conto della eventuale impostazione
 di una \textit{timezone} e effettua una chiamata preventiva a \func{tzset}
 (che vedremo a breve), in modo che la data espressa tenga conto del fuso
 orario. In realtà \func{ctime} è banalmente definita in termini di
-\func{asctime} come \code{asctime(localtime(t)}.
+\func{asctime} come \code{asctime(localtime(t))}.
 
 Dato che l'uso di una stringa statica rende le funzioni non rientranti
 POSIX.1c e SUSv2 prevedono due sostitute rientranti, il cui nome è al solito