Provided by: manpages-fr-dev_4.23.1-1_all 
NOM
prctl - Opérations sur un processus ou un thread
BIBLIOTHÈQUE
Bibliothèque C standard (libc, -lc)
SYNOPSIS
#include <sys/prctl.h>
int prctl(int op, ...
/* unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5 */ );
DESCRIPTION
prctl() gère divers aspects du comportement du thread ou du processus appelant.
Notez qu'une utilisation peu soigneuse de certaines opérations de prctl() peut perdre l'environnement
d’exécution de l'espace utilisateur, donc il faut les utiliser avec rigueur.
prctl() est invoqué avec un premier paramètre indiquant ce qu'il faut faire, (ses valeurs sont définies
dans <linux/prctl.h>), et des paramètres supplémentaires dont la signification dépend du premier
paramètre. Celui-ci peut être :
PR_CAP_AMBIENT (depuis Linux 4.3)
Lire ou modifier l'ensemble environnant des capacités paramétrées sur le thread appelant, en
fonction de la valeur de arg2, qui doit être une des suivantes :
PR_CAP_AMBIENT_RAISE
La capacité indiquée dans arg3 est ajoutée à l'ensemble environnant. Elle doit être déjà
présente dans les ensembles environnants autorisés et hérités du processus. Cette opération
n'est pas autorisée si le bit de sécurité SECBIT_NO_CAP_AMBIENT_RAISE est positionné.
PR_CAP_AMBIENT_LOWER
La capacité indiquée dans arg3 est supprimée de l'ensemble environnant.
PR_CAP_AMBIENT_IS_SET
L'appel prctl() renvoie 1 si la capacité indiquée dans arg3 est dans l'ensemble environnant
et, sinon, 0.
PR_CAP_AMBIENT_CLEAR_ALL
Toutes les capacités seront supprimées de l'ensemble environnant. Cette opération implique
que arg3 soit positionné sur zéro.
Dans toutes les opérations ci-dessus, arg4 et arg5 doivent valoir 0.
Des interfaces de plus haut niveau qui constituent la couche au-dessus des opérations ci-dessus
sont fournies dans la bibliothèque libcap(3) sous la forme cap_get_ambient(3), cap_set_ambient(3),
et cap_reset_ambient(3).
PR_CAPBSET_READ (depuis Linux 2.6.25)
Renvoyer (en résultat de fonction) 1 si la capacité indiquée par arg2 est présente dans l’ensemble
limitant de capacités du thread appelant ou 0 si elle ne l'est pas. Les constantes des capacités
sont définies dans <linux/capability.h>. L'ensemble limitant les capacités contrôle si le
processus peut recevoir la capacité par un ensemble de capacités autorisées pour un fichier lors
d'un appel futur à execve(2).
Si la capacité indiquée dans arg2 n'est pas valable, alors l'appel échoue avec l'erreur EINVAL.
Une interface de plus haut niveau constituant la couche par-dessus cette opération est fournie
dans la bibliothèque libcap(3) sous la forme cap_get_bound(3).
PR_CAPBSET_DROP (depuis Linux 2.6.25)
Si le thread appelant a la capacité CAP_SETPCAP dans son espace de noms utilisateur, alors enlever
la capacité indiquée par arg2 dans l'ensemble de limitation de capacités du thread appelant. Les
enfants du thread appelant hériteront de cette nouvelle limitation de capacités réduite.
L'appel échoue avec l'erreur EPERM si le thread appelant n'a pas la capacité CAP_SETPCAP ; ou avec
l'erreur EINVAL si arg2 ne représente pas une capacité correcte ; ou avec l'erreur EINVAL si les
capacités de fichier ne sont pas activées dans le noyau, auquel cas les limitations ne sont pas
prises en charge par le noyau.
Une interface de plus haut niveau constituant la couche au-dessus de cette opération est fournie
par la bibliothèque libcap(3) sous la forme cap_drop_bound(3).
PR_SET_CHILD_SUBREAPER (depuis Linux 3.4)
Si arg2 ne vaut pas zéro, positionner l'attribut « child subreaper » du processus appelant ; si
arg2 vaut zéro, déconfigurer l'attribut.
Un subreaper (suppresseur) joue le rôle de init(1) pour ses processus enfants. Quand un processus
devient orphelin (c'est-à-dire, que son parent le plus proche se termine), ce processus sera
adopté par le subreaper parent toujours vivant le plus proche. Par conséquent, les appels
getppid(2) dans le processus orphelin renverront désormais l'identifiant de processus du subreaper
et quand l'orphelin se terminera, c'est le processus subreaper qui recevra le signal SIGCHLD et
pourra surveiller (wait(2)) le processus pour détecter son état de fin.
Le paramètre de l'attribut « child subreaper » n'est pas récupéré par les enfants créés par
fork(2) et clone(2). Le paramètre est préservé lors d'un execve(2).
Établir un processus subreaper est utile dans les environnements de gestion de sessions où un
groupe hiérarchique de processus est géré par un processus subreaper qui a besoin de savoir quand
un des processus — par exemple, un démon forké deux fois — se termine (pour pouvoir peut-être
redémarrer ce processus). Certains environnements init(1) (comme systemd(1)) utilisent un
processus subreaper pour les mêmes raisons.
PR_GET_CHILD_SUBREAPER (depuis Linux 3.4)
Renvoyer l'état « child subreaper » du processus appelant, dans l'emplacement pointé par (int *)
arg2.
PR_SET_DUMPABLE (depuis Linux 2.3.20)
Définir l'état de l'attribut « dumpable » qui détermine si les fichiers de vidages mémoire (core
dump) sont produits pour le processus appelant lors de l'envoi du signal, dont le comportement par
défaut est de produire un fichier d’image mémoire.
Dans les noyaux jusqu'à 2.6.12 inclus, arg2 doit valoir 0 (SUID_DUMP_DISABLE, pas de vidage
mémoire) ou 1 (SUID_DUMP_USER, vidage possible). Entre les noyaux 2.6.13 et 2.6.17, la valeur 2
était également autorisée ; elle permettait à un binaire qui ne produirait normalement pas de
fichier de vidage d'en créer un lisible uniquement par root ; cette fonctionnalité a été supprimée
pour des raisons de sécurité (consultez aussi la description de /proc/sys/fs/suid_dumpable dans
proc(5)).
Normalement, l'attribut « dumpable » est positionné sur 1. Cependant, il est positionné sur la
valeur actuelle du fichier /proc/sys/fs/suid_dumpable (qui a une valeur de 0 par défaut), dans les
circonstances suivantes :
- L'identifiant d'utilisateur ou de groupe effectif du processus a été modifié.
- L'identifiant d'utilisateur ou de groupe du système de fichiers du processus a été modifié
(voir credentials(7)).
- Le processus exécute (execve(2)) un programme set-user-ID ou set-group-ID, ce qui fait changer
l'identifiant d'utilisateur ou de groupe effectif.
- Le processus exécute (execve(2)) un programme qui a les capacités de fichier (voir
capabilities(7)), mais seulement si les capacités acquises ainsi autorisées dépassent celles
autorisées pour le processus.
Les processus qui ne génèrent pas de fichier de vidage ne peuvent pas être rattachés à l'aide de
PTRACE_ATTACH de ptrace(2) ; voir ptrace(2) pour plus de détails.
Si un processus ne génère pas de fichier de vidage, l'appartenance des fichiers du répertoire
/proc/pid du processus est modifiée comme le décrit proc(5).
PR_GET_DUMPABLE (depuis Linux 2.3.20)
Renvoyer (en résultat de fonction) l'état actuel de l'attribut de création de fichier de vidage du
processus appelant.
PR_SET_ENDIAN (depuis Linux 2.6.18, seulement sur PowerPC)
Définir le boutisme (endianness) du processus appelant à la valeur donnée dans arg2, qui doit être
l'une des valeurs suivantes : PR_ENDIAN_BIG, PR_ENDIAN_LITTLE, ou PR_ENDIAN_PPC_LITTLE (PowerPC
pseudo petit boutiste).
PR_GET_ENDIAN (depuis Linux 2.6.18, seulement sur PowerPC)
Renvoyer le boutisme (endianness) du processus appelant, dans l'emplacement pointé par (int *)
arg2.
PR_SET_FP_MODE (depuis Linux 4.0, seulement sur MIPS)
Sur l'architecture MIPS, le code en espace utilisateur peut être construit en utilisant une ABI
qui permet l'édition de liens avec du code ayant des exigences de virgule flottante (FP) plus
restrictives. Par exemple, un code en espace utilisateur peut être construit pour cibler l'ABI
FPXX O32 et lié au code construit pour une ou plusieurs ABI plus restrictives FP32 ou FP64. Quand
du code plus restrictif est lié, l'exigence supplémentaire du processus est d'utiliser le mode de
virgule flottante plus restrictif.
Le noyau n'ayant aucun moyen de savoir à l'avance le mode dans lequel doit être exécuté le
processus, et ces restrictions pouvant changer durant la vie du processus, l'opération
PR_SET_FP_MODE est fournie pour permettre un contrôle du mode de virgule flottante à partir de
l'espace utilisateur.
L'argument (unsigned int) arg2 est un masque de bits décrivant le mode de virgule flottante
utilisé :
PR_FP_MODE_FR
Quand le bit est unset (ce qui est appelé le mode FR=0 ou FR0), les registres 32 de virgule
flottante ont une taille de 32 bits et ceux 64 bits sont représentés sous forme de paire de
registres (numérotés par un nombre pair ou impair, avec le registre pair contenant les
32 bits de poids faible et celui impair contenant les 32 bits de poids fort).
Quand ce bit est set (sur le matériel pris en charge), les registres 32 de virgule
flottante ont une taille de 64 bits (ce qui est appelé le mode FR=1 ou FR1). Remarquez que
les implémentations MIPS modernes (MIPS R6 et plus récentes) ne gèrent que le mode FR=1.
Les applications qui utilisent l'ABI O32 FP32 ne peuvent fonctionner que lorsque ce bit est
unset (FR=0 ; ou elles peuvent être utilisées avec FRE activé, voir ci-dessous). Les
applications qui utilisent l'ABI O32 FP64 (et l'ABI O32 FP64A qui existe pour offrir la
capacité d'agir avec le code FP32 existant ; voir ci-dessous) ne peuvent agir que quand ce
bit est set (FR=1). Les applications qui utilisent l'ABI O32 FPXX peuvent agir avec FR=0 ou
FR=1.
PR_FP_MODE_FRE
Activer l'émulation du mode flottant 32 bits. Quand ce mode est activé, il émule les
opérations de virgule flottante 32 bits en plaçant une exception d'instruction réservée sur
chaque instruction utilisant les formats 32 bits et le noyau prend alors en charge
l'instruction au niveau logiciel (c'est le problème du décalage entre la gestion des
registres aux numéros pairs , qui sont les 32 bits supérieurs des registres 64 bits ayant
les numéros impairs en mode FR=0, et les parties 32 bits de poids faible des registres
64 bits de numéros impairs en mode FR=1). L'activation de ce bit est nécessaire pour du
code dont l'ABI O32 FP3 doit agir sur du code ayant des ABI compatibles O32 FPXX ou O32
FP64A (ce qui implique le mode FR=1 FPU), ou lorsqu'il est exécuté sur du matériel plus
récent (après MIPS R6) qui ne prend pas en charge le mode FR=0 quand un binaire avec l'ABI
FP32 est utilisé.
Remarquez que ce mode n'a de sens que lorsque le FPU est en mode 64 bits (FR=1).
Remarquez que l'utilisation de l'émulation a par nature des conséquences en termes de
performance et qu’elle doit être évitée si possible.
Dans l'ABI N32/N64, le mode de virgule flottante 64 bits est toujours utilisé, l'émulation FPU
n'est donc pas nécessaire et le mode FPU agit toujours en mode FR=1.
Cette opération vise principalement les éditeurs de liens dynamiques (ld.so(8)).
Les paramètres arg3, arg4 et arg5 sont ignorés.
PR_GET_FP_MODE (depuis Linux 4.0, seulement sur MIPS)
Renvoyer (comme résultat de la fonction) le mode de virgule flottante actuel (voir la description
de PR_SET_FP_MODE pour les détails).
En cas de succès, l'appel renvoie un masque de bits qui représente le mode de virgule flottante
actuel.
Les paramètres arg2, arg3, arg4 et arg5 sont ignorés.
PR_SET_FPEMU (depuis Linux 2.4.18, 2.5.9, seulement sur ia64)
Définir les bits de contrôle de l'émulation de virgule flottante à arg2. Passer PR_FPEMU_NOPRINT
pour émuler silencieusement les opérations de virgule flottante, ou PR_FPEMU_SIGFPE pour ne pas
émuler ces opérations et envoyer SIGFPE.
PR_GET_FPEMU (depuis Linux 2.4.18, 2.5.9, seulement sur ia64)
Renvoyer les bits de contrôle de l'émulation de FPU dans l'emplacement vers lequel pointe (int *)
arg2.
PR_SET_FPEXC (depuis Linux 2.4.21, 2.5.32, seulement sur PowerPC)
Définir le mode d'exception de virgule flottante à arg2. Passer la valeur PR_FP_EXC_SW_ENABLE pour
utiliser FPEXC pour activer les exceptions de flottant, PR_FP_EXC_DIV pour les divisions de
flottant par zéro, PR_FP_EXC_OVF pour les dépassements de capacité vers le haut, PR_FP_EXC_UND
pour les dépassements de capacité vers le bas, PR_FP_EXC_RES pour les résultats de flottant
inexacts, PR_FP_EXC_INV pour les opérations de flottant non valables, PR_FP_EXC_DISABLED pour
désactiver les exceptions de flottant, PR_FP_EXC_NONRECOV pour le mode d'exception asynchrone non
récupérable, PR_FP_EXC_ASYNC pour le mode d'exception asynchrone récupérable, PR_FP_EXC_PRECISE
pour le mode d'exception de précision.
PR_GET_FPEXC (depuis Linux 2.4.21, 2.5.32, seulement sur PowerPC)
Renvoyer le mode d'exception de virgule flottante dans l'emplacement vers lequel pointe (int *)
arg2.
PR_SET_IO_FLUSHER (depuis Linux 5.6)
Si le processus d'un utilisateur est impliqué dans la couche de blocs ou le chemin d'E/S du
système de fichiers, et s'il peut allouer de la mémoire en traitant les requêtes E/S, il doit
positionner arg2 sur 1. Cela mettra le processus en état IO_FLUSHER, ce qui lui accorde un
traitement spécial pour progresser lors de l'allocation de la mémoire. Si arg2 vaut 0, le
processus effacera l'état IO_FLUSHER et le comportement par défaut sera utilisé.
Le processus appelant doit avoir la capacité CAP_SYS_RESOURCE.
arg3, arg4 et arg5 doivent valoir 0.
L'état IO_FLUSHER est récupéré par un processus enfant créé à l'aide de fork(2) et il est préservé
pendant un execve(2).
Des exemples d'applications IO_FLUSHER sont les démons FUSE, ceux d'émulation de périphériques
SCSI et ceux gérant des erreurs comme les applications de récupération de chemins multipath.
PR_GET_IO_FLUSHER (depuis Linux 5.6)
Renvoyer (en tant que résultat de la fonction) l'état IO_FLUSHER de l'appelant. Une valeur de 1
indique que l'appelant est dans l'état IO_FLUSHER ; 0 indique qu'il n'est pas dans cet état.
Le processus appelant doit avoir la capacité CAP_SYS_RESOURCE.
arg2, arg3, arg4 et arg5 doivent valoir zéro.
PR_SET_KEEPCAPS (depuis Linux 2.2.18)
Définir l'état de l'attribut « keep capabilities » du thread appelant. L'effet de cet attribut est
décrit dans capabilities(7). arg2 doit valoir soit 0 (effacer l'attribut), soit 1 (positionner
l'attribut). La valeur de « keep capabilities » sera remise à 0 lors des prochains appels à
execve(2).
PR_GET_KEEPCAPS (depuis Linux 2.2.18)
Renvoyer (en résultat de fonction) l'état actuel de l'attribut de conservation des capacités du
thread appelant. Voir capabilities(7) pour une description de cet attribut.
PR_MCE_KILL (depuis Linux 2.6.32)
Définir la politique de suppression de mémoire corrompue de la machine pour le thread actuel. Si
arg2 vaut PR_MCE_KILL_CLEAR, effacer la politique de suppression de mémoire corrompue et utiliser
la valeur par défaut du système (qui est définie dans /proc/sys/vm/memory_failure_early_kill,
consultez proc(5)). Si arg2 vaut PR_MCE_KILL_SET, utiliser une politique de suppression de mémoire
corrompue spécifique au thread. Dans ce cas, arg3 définit si la politique est immédiate (early
kill avec PR_MCE_KILL_EARLY), différée (late kill avec PR_MCE_KILL_LATE), ou la valeur par défaut
du système (PR_MCE_KILL_DEFAULT). Une suppression immédiate signifie que le thread reçoit un
signal SIGBUS dès que la corruption mémoire matérielle est détectée à l'intérieur de son espace
d'adressage. En mode différé, le processus n'est tué que lorsqu'il accède à une page corrompue.
Consultez sigaction(2) pour plus d'informations sur le signal SIGBUS. Cette politique est héritée
par les enfants. Les arguments restants de prctl(), non utilisés, doivent être mis à zéro pour
préparer la future compatibilité.
PR_MCE_KILL_GET (depuis Linux 2.6.32)
Renvoyer (comme résultat de la fonction) la politique actuelle par processus de suppression de
mémoire corrompue. Tous les arguments de prctl() non utilisés doivent être zéro
PR_SET_MM (depuis Linux 3.3)
Modifier certains champs du descripteur de projection de mémoire du noyau pour le processus
appelant. D'habitude, ces champs sont déterminés par le noyau et le chargeur de liens dynamiques
(consultez ld.so(8) pour plus d'informations) et une application normale ne devrait pas utiliser
cette fonctionnalité. En revanche, dans certaines situations, telles que celles de programmes se
modifiant eux-mêmes, un programme pourra trouver utile de pouvoir changer sa propre projection en
mémoire.
Le processus appelant doit avoir la capacité CAP_SYS_RESOURCE. La valeur de arg2 est une des
options ci-dessous, tandis que arg3 fournit la nouvelle valeur pour l'option. Les paramètres de
arg4 et de arg5 doivent être de 0 s'ils ne sont pas utilisés.
Avant Linux 3.10, cette fonctionnalité n'est disponible que si le noyau est construit avec
l'option CONFIG_CHECKPOINT_RESTORE.
PR_SET_MM_START_CODE
Définir l'adresse au dessus de laquelle le texte du programme peut être exécuté. La zone de
mémoire correspondante doit être accessible en lecture et en exécution, mais pas en
écriture et ne doit pas pouvoir être partagée (consultez mprotect(2) et mmap(2) pour plus
d'informations).
PR_SET_MM_END_CODE
Définir l'adresse en dessous de laquelle le texte du programme peut être exécuté. La zone
de mémoire correspondante doit être accessible en lecture et en exécution, mais pas en
écriture et ne doit pas pouvoir être partagée.
PR_SET_MM_START_DATA
Définir l'adresse au-dessus de laquelle les données initialisées et non initialisées (bss)
sont placées. La zone de mémoire correspondante doit être accessible en lecture et en
écriture, mais pas en exécution et ne doit pas pouvoir être partagée.
PR_SET_MM_END_DATA
Définir l'adresse en dessous de laquelle les données initialisées et non initialisées (bss)
sont placées. La zone de mémoire correspondante doit être accessible en lecture et en
écriture, mais pas en exécution et ne doit pas pouvoir être partagée.
PR_SET_MM_START_STACK
Sélectionner l'adresse du début de la pile. La région de mémoire correspondante doit être
accessible en lecture et en écriture.
PR_SET_MM_START_BRK
Sélectionner l'adresse au-dessus de laquelle le tas du programme peut être étendu avec
l'appel brk(2). L'adresse doit être au-dessus de l'adresse terminant le segment de données
actuel du programme. De plus, la taille combinée du tas obtenu et du segment de données ne
peut pas dépasser la limite de ressource RLIMIT_DATA (consultez setrlimit(2)).
PR_SET_MM_BRK
Sélectionnez la valeur actuelle de brk(2). Les conditions pour l'adresse sont les mêmes que
pour l'option PR_SET_MM_START_BRK.
Les options suivantes sont disponibles depuis Linux 3.5.
PR_SET_MM_ARG_START
Sélectionner l'adresse au-dessus de laquelle la ligne de commande du programme est placée.
PR_SET_MM_ARG_END
Sélectionner l'adresse en dessous de laquelle la ligne de commande du programme est placée.
PR_SET_MM_ENV_START
Sélectionner l'adresse au-dessus de laquelle l'environnement du programme est placé.
PR_SET_MM_ENV_END
Sélectionner l'adresse en dessous de laquelle l'environnement du programme est placé.
L'adresse transmise au moyen de PR_SET_MM_ARG_START, PR_SET_MM_ARG_END,
PR_SET_MM_ENV_START et de PR_SET_MM_ENV_END doit appartenir à l'espace mémoire d'une pile
de processus. Par conséquent, l'espace mémoire correspondant doit être accessible en
lecture, en écriture et (selon la configuration du noyau) disposer de l'attribut
MAP_GROWSDOWN défini (consultez mmap(2)).
PR_SET_MM_AUXV
Sélectionner le nouveau vecteur auxiliaire. Le paramètre arg3 doit fournir l'adresse du
vecteur. Le paramètre arg4 est la taille du vecteur.
PR_SET_MM_EXE_FILE
Remplacer le lien symbolique /proc/pid/exe par un nouveau lien pointant vers un nouveau
fichier exécutable identifié par le descripteur de fichier fourni à l'aide du paramètre
arg3. Le descripteur de fichier peut être obtenu au moyen d'un appel à open(2).
Pour changer le lien symbolique, il faut supprimer tous les espaces alloués en mémoire et
contenant du code exécutable, y compris ceux créés par le noyau (par exemple, le noyau crée
en général au moins un espace mémoire d'exécutable pour la section ELF .text).
Sur Linux 4.9 et antérieurs, l'opération PR_SET_MM_EXE_FILE ne peut être effectuée qu'une
fois dans la vie d'un processus ; si on l'effectue une seconde fois, elle donnera l'erreur
EPERM. Cette restriction a été renforcée pour des raisons de sécurité jugées plus tard
curieuses, donc la restriction a été supprimée dans Linux 4.10 car certaines applications
en espace utilisateur avaient besoin d'effectuer cette opération plus d'une fois.
Les options suivantes sont disponibles depuis Linux 3.18.
PR_SET_MM_MAP
Fournir un accès unique à toutes les adresses en passant une struct prctl_mm_map (comme
défini dans <linux/prctl.h>). Le paramètre arg4 doit fournir la taille de la structure.
Cette fonctionnalité n'est disponible que si le noyau a été construit avec l'option
CONFIG_CHECKPOINT_RESTORE activée.
PR_SET_MM_MAP_SIZE
Renvoyer la taille attendue par le noyau de la struct prctl_mm_map. Cela permet à l'espace
utilisateur de trouver une structure compatible. Le paramètre arg4 doit être un pointeur
vers un entier non signé.
Cette fonctionnalité n'est disponible que si le noyau a été construit avec l'option
CONFIG_CHECKPOINT_RESTORE activée.
PR_SET_VMA (depuis Linux 5.17)
Positionner un attribut indiqué dans arg2 pour les zones de mémoire virtuelles commençant à
l'adresse indiquée dans arg3 et couvrant la taille indiquée dans arg4. arg5 indique la valeur de
l'attribut à positionner.
Remarquez que l'affectation d'un attribut à une zone de mémoire virtuelle pourrait l'empêcher de
se fusionner avec les zones adjacentes du fait d'une différence de valeur de cet attribut.
Actuellement, arg2 doit valoir une des valeurs suivantes :
PR_SET_VMA_ANON_NAME
Définir un nom pour les zones de mémoire virtuelle anonymes. arg5 doit être un pointeur
vers une chaîne se terminant par l’octet NULL contenant le nom. La taille du nom, y compris
l'octet NULL, ne peut pas dépasser 80 octets. Si arg5 vaut NULL, le nom des zones de
mémoire virtuelle anonymes adéquat sera réinitialisé. Le nom ne peut contenir que des
caractères ASCII imprimables (dont des espaces), sauf « [ », « ] », « \ », « $ » et « ` ».
PR_MPX_ENABLE_MANAGEMENT
PR_MPX_DISABLE_MANAGEMENT (depuis Linux 3.19, supprimée dans Linux 5.4 ; seulement sur x86)
Activer ou désactiver la gestion par le noyau des tables de limitations Memory Protection
eXtensions (MPX). Les paramètres arg2, arg3, arg4 et arg5 doivent valoir zéro.
MPX est un mécanisme assisté par le matériel pour effectuer des contrôles de limites sur les
pointeurs. Il consiste dans un ensemble de registres stockant les informations des limites et un
ensemble de préfixes d'instruction spéciaux qui disent au processeur sur quelle instruction il
doit poser des limites renforcées. Il existe un nombre limité de ces registres et quand il y a
plus de pointeurs que de registres, leur contenu doit être « déversé » (spilled) dans un ensemble
de tables. Ces tables s'appellent des « bounds tables » et les opérations prctl() de MPX décident
si le noyau gère leur allocation ou leur libération.
Quand la gestion est activée, le noyau prendra en charge l'allocation et la libération des tables
de limites. Il le fait en piégeant les exceptions #BR qui conduisent d’abord à l'utilisation de
tables de limites manquantes, et au lieu d'envoyer l'exception à l'espace utilisateur, il alloue
la table et remplit le répertoire des limites avec l'emplacement de la nouvelle table. Pour la
libération, le noyau vérifie dans les tables de limites la présence de mémoire non allouée et les
libère.
Avant d'activer la gestion MPX en utilisant PR_MPX_ENABLE_MANAGEMENT, l'application doit d'abord
avoir alloué un tampon dans l'espace utilisateur pour le répertoire de limites, et placé
l'emplacement de ce répertoire dans le registre bndcfgu.
Ces appels échouent si le processeur ou le noyau ne gèrent pas MPX. La prise en charge par le
noyau de MPX s'active avec l'option de configuration CONFIG_X86_INTEL_MPX. Vous pouvez vérifier
que le processeur prend en charge MPX en recherchant le bit de CPUID mpx, avec une commande telle
que :
cat /proc/cpuinfo | grep ' mpx '
Il se peut qu'un thread ne bascule pas en ou hors du mode long (64 bits) quand MPX est activé.
Tous les threads d'un processus sont concernés par ces appels.
L'enfant d'un fork(2) hérite de l'état de la gestion MPX. Pendant un execve(2), la gestion MPX est
réinitialisée à un état tel que si PR_MPX_DISABLE_MANAGEMENT avait été appelé.
Pour plus d'informations sur le MPX d'Intel, consultez le fichier Documentation/x86/intel_mpx.txt
dans les sources du noyau.
Du fait d'un manque de prise en charge de l'ensemble d'outils, PR_MPX_ENABLE_MANAGEMENT et
PR_MPX_DISABLE_MANAGEMENT ne sont pas gérés dans Linux 5.4 et ultérieurs.
PR_SET_NAME (depuis Linux 2.6.9)
Définir le nom du thread appelant, en utilisant la valeur de l'emplacement vers lequel pointe
(char *) arg2. Le nom peut avoir jusqu'à 16 octets de long, y compris l’octet NULL final (en cas
de dépassement, octet NULL final inclus, la chaîne est tronquée silencieusement). C’est le même
attribut qui peut être défini par pthread_setname_np(3) et consulté par pthread_getname_np(3). On
peut également y accéder à l’aide de /proc/self/task/tid/comm (voir proc(5)), où tid désigne
l'identifiant du thread appelant tel que renvoyé par gettid(2).
PR_GET_NAME (depuis Linux 2.6.11)
Renvoyer le nom du thread appelant, dans le tampon vers lequel pointe (char *) arg2. Le tampon
doit être suffisamment grand pour contenir jusqu'à 16 octets ; la chaîne sera terminée par un
octet NULL.
PR_SET_NO_NEW_PRIVS (depuis Linux 3.5)
Affecter au bit no_new_privs du processus appelant la valeur dans arg2. Lorsque no_new_privs a la
valeur 1, execve(2) promet de ne pas donner de droits à quoi que ce soit qui n'aurait pas pu être
fait sans l'appel execve(2) (par exemple, rendre non fonctionnels les bits de permission
set-user-ID et set-group-ID, ou bien les capacités de fichiers). Une fois affecté, le bit ne peut
pas être réinitialisé. L'affectation de ce bit est héritée par les enfants créés par fork(2) et
clone(2) et préservée à travers execve(2).
Depuis Linux 4.10, la valeur de l'attribut no_new_privs d'un thread est visible dans le champ
NoNewPrivs du fichier /proc/pid/status.
Pour plus d'informations, consultez le fichier Documentation/userspace-api/no_new_privs.rst (ou
Documentation/prctl/no_new_privs.txt avant Linux 4.13) dans les sources du noyau. Voir seccomp(2).
PR_GET_NO_NEW_PRIVS (depuis Linux 3.5)
Renvoyer (comme résultat de la fonction) la valeur du bit no_new_privs du thread appelant. La
valeur 0 indique le comportement habituel de execve(2). La valeur 1 indique que execve(2) va
opérer dans le mode limiteur de droits décrit ci-dessus.
PR_PAC_RESET_KEYS (depuis Linux 5.0, seulement sur arm64)
Réinitialiser de manière sûre les clés d'authentification du pointeur du thread pour rafraîchir
les valeurs aléatoires générées par le noyau.
Le jeu de clés à réinitialiser est indiqué avec arg2, qui doit être un OU logique de zéro ou
plusieurs des valeurs suivantes :
PR_PAC_APIAKEY
clé A d'authentification d'instruction
PR_PAC_APIBKEY
clé B d'authentification d'instruction
PR_PAC_APDAKEY
clé A d'authentification de données
PR_PAC_APDBKEY
clé B d'authentification de données
PR_PAC_APGAKEY
clé “A” d'authentification générique
(Oui les amis, il n'y a vraiment pas de clé B générique).
Il existe un cas particulier où si arg2 vaut 0, toutes les clés sont réinitialisées. Comme de
nouvelles clés pourraient être ajoutées dans le futur, c'est la manière recommandée pour nettoyer
les clés existantes pour créer un contexte d'exécution propre. Remarquez qu'il n'est pas
nécessaire d'utiliser PR_PAC_RESET_KEYS pour préparer un appel execve(2), puisque execve(2)
réinitialise toutes les clés d'authentification des pointeurs.
Les autres arguments arg3, arg4 et arg5 doivent être nuls.
Si les paramètres ne sont pas valables, et notamment si arg2 contient des bits non reconnus ou
correspondant à une clé indisponible sur cette plateforme, l'appel échoue avec l'erreur EINVAL.
Attention : le compilateur ou l'environnement d'exécution pouvant utiliser tout ou partie des
clés, un PR_PAC_RESET_KEYS réussi peut faire planter le processus appelant. Les conditions pour
l'utiliser en toute sécurité sont complexes et dépendent du système. Ne l'utilisez pas sauf si
vous savez ce que vous faites.
Pour plus d'informations, consultez le fichier Documentation/arm64/pointer-authentication.rst (ou
Documentation/arm64/pointer-authentication.txt avant Linux 5.3) dans les sources du noyau.
PR_SET_PDEATHSIG (depuis Linux 2.1.57)
Configurer le signal de mort du parent du processus appelant avec la valeur arg2 (qui peut être un
numéro de signal dans l'intervalle [1, NSIG - 1] ou 0 pour effacer le signal). Il s'agit du numéro
du signal que le processus appelant recevra si son parent meurt.
Attention : c'est le thread qui est, dans ce cas, considéré comme le « parent » qui a créé ce
processus. Autrement dit, le signal sera envoyé quand ce thread se terminera (à l'aide de
pthread_exit(3), par exemple) et non après que tous les threads du processus parent ne se soient
terminés.
Le signal de la mort du parent est envoyé lors de la fin ultérieure du thread parent et lors de la
fin de chaque processus subreaper (voir la description de PR_SET_CHILD_SUBREAPER ci-dessus) auquel
l'appelant est alors affilié. Si le thread parent et tous les subreapers ancêtres sont déjà
terminés au moment de l'opération PR_SET_PDEATHSIG, aucun signal de la mort du parent n'est envoyé
à l'appelant.
Le signal de la mort du parent est envoyé au processus (voir signal(7)) et, si l'enfant installe
un gestionnaire en utilisant l'attribut SA_SIGINFO de sigaction(2), le champ si_pid du paramètre
siginfo_t du gestionnaire contient l'identifiant du processus parent qui se termine.
Le paramétrage de signal de mort du parent est vidé pour l'enfant d'un fork(2). Il est également
vidé (depuis Linux 2.4.36/2.6.23) lors de l'exécution d'un binaire Set-UID ou Set-GID ou d'un
binaire qui a des capacités associées (voir capabilities(7)) ; sinon cette valeur est préservée
par execve(2). Le paramétrage du signal de mort du parent est aussi vidé lors du changement des
droits suivants d'un thread : l'identifiant utilisateur ou de groupe effectif, l'identifiant
utilisateur ou groupe du système de fichiers.
PR_GET_PDEATHSIG (depuis Linux 2.3.15)
Renvoyer la valeur actuelle du signal de mort du processus parent, dans l'emplacement vers lequel
pointe (int *) arg2.
PR_SET_PTRACER (depuis Linux 3.4)
Cela n'a de sens que lorsque le LSM Yama est actif et en mode 1 ("restricted ptrace", visible dans
/proc/sys/kernel/yama/ptrace_scope). Lorsqu'un identifiant de processus ptracer (« ptracer process
ID ») est passé en argument arg2, le composant appelant déclare que le processus ptracer peut
appeler la fonction ptrace(2) appliquée au processus appelant, comme si celui-ci était un ancêtre
direct. Chaque opération PR_SET_PTRACER remplace l'identifiant du processus ptracer précédent.
L'emploi de PR_SET_PTRACER avec l'argument arg2 égal à 0 supprime tous les identifiants de
processus ptracer de l'appelant. Si arg2 est égal à PR_SET_PTRACER_ANY, les restrictions ptrace
apportées par Yama sont de fait désactivées pour le processus appelant.
Pour plus d'informations, consultez le fichier Documentation/admin-guide/LSM/Yama.rst dans les
sources du noyau (ou Documentation/security/Yama.txt avant Linux 4.13).
PR_SET_SECCOMP (depuis Linux 2.6.23)
Sélectionner le mode de traitement sécurisé (seccomp) pour le thread appelant, afin de limiter les
appels système disponibles. L'appel système plus récent seccomp(2) fournit un superensemble de
fonctions de PR_SET_SECCOMP et il est l'interface privilégiée pour les nouvelles applications.
Le mode de traitement sécurisé est sélectionné par arg2 (les constantes du mode de traitement
sécurisé sont définies dans <linux/seccomp.h>). Les valeurs suivantes peuvent être indiquées :
SECCOMP_MODE_STRICT (depuis Linux 2.6.23)
Voir la description de SECCOMP_SET_MODE_STRICT dans seccomp(2).
Cette fonctionnalité n'est disponible que si le noyau a été construit avec l'option
CONFIG_SECCOMP activée.
SECCOMP_MODE_FILTER (depuis Linux 3.5)
Les appels système autorisés sont définis par un pointeur vers un filtre de paquets
Berkeley passé en arg3. Cet argument est un pointeur vers struct sock_fprog ; il peut être
conçu pour filtrer des appels système arbitraires et les arguments des appels système.
Consulter la description de SECCOMP_SET_MODE_FILTER dans seccomp(2).
Cette fonctionnalité n'est disponible que si le noyau a été construit avec l'option
CONFIG_SECCOMP_FILTER activée.
Pour plus de détails sur le filtrage seccomp, voir seccomp(2).
PR_GET_SECCOMP (depuis Linux 2.6.23)
Renvoyer (comme résultat de la fonction) le mode de traitement sécurisé du thread appelant. Si
l'appelant n'est pas dans un mode de traitement sécurisé, cette opération renvoie 0 ; si
l'appelant est dans le mode de traitement sécurisé strict, alors l'appel prctl() provoquera
l'envoi d'un signal SIGKILL au processus. Si l'appelant est dans le mode filtre et que cet appel
système est autorisé par les filtres seccomp, cette opération renvoie 2 ; sinon le processus est
tué avec un signal SIGKILL.
Cette fonctionnalité n'est disponible que si le noyau a été construit avec l'option CONFIG_SECCOMP
activée.
Depuis Linux 3.8, le champ Seccomp du fichier /proc/pid/status offre une méthode pour obtenir la
même information sans risquer que le processus ne soit tué ; voir proc(5).
PR_SET_SECUREBITS (depuis Linux 2.6.26)
Configurer l'attribut « securebits » du thread appelant à la valeur fournie par arg2. Consultez
capabilities(7).
PR_GET_SECUREBITS (depuis Linux 2.6.26)
Renvoyer (en résultat de fonction) l'état actuel de l'attribut « securebits » du thread appelant.
Consultez capabilities(7).
PR_GET_SPECULATION_CTRL (depuis Linux 4.17)
Renvoyer (en tant que résultat de la fonction) l'état de la fonction défectueuse de spéculation
indiquée dans arg2. Actuellement, la seule valeur autorisée pour ce paramètre est
PR_SPEC_STORE_BYPASS (sans quoi l'appel échoue avec l'erreur ENODEV).
Le code de retour utilise les bits 0 à 3 ayant la signification suivante :
PR_SPEC_PRCTL
L'atténuation peut être contrôlée par thread via PR_SET_SPECULATION_CTRL.
PR_SPEC_ENABLE
La fonction de spéculation est activée, l'atténuation est désactivée.
PR_SPEC_DISABLE
La fonction de spéculation est désactivée, l'atténuation est activée.
PR_SPEC_FORCE_DISABLE
Identique à PR_SPEC_DISABLE mais ne peut pas être annulé.
PR_SPEC_DISABLE_NOEXEC (depuis Linux 5.1)
Identique à PR_SPEC_DISABLE, mais l'état sera vidé pendant un execve(2).
Si tous les bits valent 0, le processeur n'est pas concerné par la fonction défectueuse de
spéculation.
Si PR_SPEC_PRCTL est positionné, le contrôle par thread de l'atténuation est disponible. Sinon,
prctl() échouera pour la fonction défectueuse de spéculation.
Les paramètres arg3, arg4 et arg5 doivent être indiqués en tant que 0 ; sinon l'appel échoue avec
l'erreur EINVAL.
PR_SET_SPECULATION_CTRL (depuis Linux 4.17)
Définir l'état de la fonction défectueuse de spéculation indiqué dans arg2. Ces paramètres sont
des attributs par thread.
Actuellement, arg2 doit valoir une des valeurs suivantes :
PR_SPEC_STORE_BYPASS
Définir l'état de la fonction défectueuse de contournement de stockage spéculatif.
PR_SPEC_INDIRECT_BRANCH (depuis Linux 4.20)
Positionner l'état de la fonction défectueuse de spéculation de branche indirecte.
Si arg2 n'a pas une des valeurs ci-dessus, l'appel échoue avec l'erreur ENODEV.
Le paramètre arg3 est utilisé pour récupérer le code de contrôle, qui peut être un des suivants :
PR_SPEC_ENABLE
La fonction de spéculation est activée, l'atténuation est désactivée.
PR_SPEC_DISABLE
La fonction de spéculation est désactivée, l'atténuation est activée.
PR_SPEC_FORCE_DISABLE
Identique à PR_SPEC_DISABLE, mais ne peut pas être annulé. Un prctl( arg2, PR_SPEC_ENABLE)
ultérieur avec la même valeur pour arg2 échouera avec l'erreur EPERM.
PR_SPEC_DISABLE_NOEXEC (depuis Linux 5.1)
Identique à PR_SPEC_DISABLE, mais l'état sera vidé lors d'un execve(2). Actuellement, seul
arg2 égal à PR_SPEC_STORE_BYPASS est pris en charge.
Toute valeur non valable de arg3 fera échouer l'appel avec l'erreur ERANGE.
Les paramètres arg4 et arg5 doivent être indiqués en tant que 0 ; sinon l'appel échoue avec
l'erreur EINVAL.
La fonctionnalité de spéculation peut aussi être gérée par l'option d'amorçage
spec_store_bypass_disable. Ce paramètre applique une règle de lecture seule qui fera échouer un
appel prctl() avec une erreur ENXIO. Pour de plus amples détails, voir le fichier
Documentation/admin-guide/kernel-parameters.txt des sources du noyau.
PR_SVE_SET_VL (depuis Linux 4.15, seulement sur arm64)
Configurer la taille du vecteur SVE du thread comme indiqué dans (int) arg2. Les paramètres arg3,
arg4 et arg5 sont ignorés.
Les bits de arg2 correspondant à PR_SVE_VL_LEN_MASK doivent être positionnés sur la taille
souhaitée du vecteur en octets. Elle est interprétée comme une limite supérieure : le noyau
sélectionnera la taille de vecteur disponible la plus grande qui ne dépasse pas celle indiquée. En
particulier, indiquer SVE_VL_MAX (défini dans <asm/sigcontext.h>) pour les bits PR_SVE_VL_LEN_MASK
exige la taille maximale de vecteur prise en charge.
En outre, les autres bits de arg2 doivent être positionnés sur une des combinaisons suivantes
d'attributs :
0 Effectuer les modifications immédiatement. Lors du prochain execve(2) dans le thread, la
taille du vecteur sera réinitialisée à celle configurée dans
/proc/sys/abi/sve_default_vector_length.
PR_SVE_VL_INHERIT
Effectuer les changements immédiatement. Les prochains appels execve(2) préserveront la
nouvelle taille du vecteur.
PR_SVE_SET_VL_ONEXEC
Différer la modification pour qu'elle soit effectuée au prochain execve(2) dans le thread.
Les appels execve(2) suivants réinitialiseront la taille du vecteur à la valeur configurée
dans /proc/sys/abi/sve_default_vector_length.
PR_SVE_SET_VL_ONEXEC | PR_SVE_VL_INHERIT
Différer la modification pour qu'elle soit effectuée au prochain execve(2) dans le thread.
Les prochains appels execve(2) préserveront la nouvelle taille du vecteur.
Dans tous les cas, toute modification précédemment différée et en attente sera annulée.
L'appel échoue avec l'erreur EINVAL si SVE n'est pas géré par la plateforme, si arg2 n'est pas
reconnu ou n'est pas valable, ou si la valeur des bits de arg2 correspondant à PR_SVE_VL_LEN_MASK
dépasse la plage SVE_VL_MIN..SVE_VL_MAX ou n'est pas un multiple de 16.
En cas de succès, une valeur non négative est renvoyée décrivant la configuration de selected. Si
PR_SVE_SET_VL_ONEXEC faisait partie de arg2, la configuration décrite par le code de retour
prendra effet au prochain execve(). Sinon, la configuration s'applique déjà quand l'appel
PR_SVE_SET_VL renvoie. Dans les deux cas, la valeur est encodée de la même façon que le code de
retour de PR_SVE_GET_VL. Remarquez qu'il n'y a pas d'attribut explicite dans le code de retour
correspondant à PR_SVE_SET_VL_ONEXEC.
La configuration (y compris les modifications différées en attente) est récupérée lors d'un
fork(2) et d'un clone(2).
Pour plus d'informations, consultez le fichier Documentation/arm64/sve.rst dans les sources du
noyau (ou Documentation/arm64/sve.txt avant Linux 5.3).
Attention : le compilateur ou l'environnement d'exécution pouvant utiliser SVE, l'utilisation de
cet appel sans l'attribut PR_SVE_SET_VL_ONEXEC peut faire planter le processus appelant. Les
conditions nécessaires pour une utilisation sûre sont complexes et dépendent du système. Ne
l'utilisez pas sauf si vous savez vraiment ce que vous faites.
PR_SVE_GET_VL (depuis Linux 4.15, seulement sur arm64)
Récupérer la configuration de la taille du vecteur SVE du thread actuel.
Les paramètres arg2, arg3, arg4 et arg5 sont ignorés.
Si le noyau et la plateforme gèrent SVE, cette opération réussit toujours, en renvoyant une valeur
non négative qui décrit la configuration actuelle. Les bits correspondant à PR_SVE_VL_LEN_MASK
contiennent la taille du vecteur actuellement configuré en octets. Le bit correspondant à
PR_SVE_VL_INHERIT indique si la taille du vecteur sera récupérée à travers execve(2).
Remarquez qu'il n'y a aucun moyen de savoir s'il y a un changement de taille de vecteur en attente
non encore appliqué.
Pour plus d'informations, consultez le fichier Documentation/arm64/sve.rst dans les sources du
noyau (ou Documentation/arm64/sve.txt avant Linux 5.3).
PR_SET_SYSCALL_USER_DISPATCH (depuis Linux 5.11, seulement sur x86)
Configurer le mécanisme « Syscall User Dispatch » pour le thread appelant. Ce mécanisme permet à
une application d'intercepter de manière sélective les appels système pour qu'elle puisse les
gérer elle-même. L'interception prend la forme d'un signal SIGSYS envoyé au thread quand il
effectue un appel système. S'il est intercepté, l'appel système n'est pas exécuté par le noyau.
Pour activer ce mécanisme, arg2 doit être positionné sur PR_SYS_DISPATCH_ON. Les prochains appels
système seront alors sélectivement interceptés selon la valeur d'une variable de contrôle fournie
dans l'espace utilisateur. Dans ce cas, arg3 et arg4 identifient respectivement la position et la
taille d'une zone de mémoire continue dans l'espace d'adressage du processus où les appels système
sont toujours autorisés à être exécutés, quelle que soit la valeur de la variable de contrôle
(cette zone inclut généralement la zone de mémoire contenant la bibliothèque C).
arg5 pointe vers une variable de taille caractère qui représente un paramètre rapide pour
autoriser/empêcher l'exécution d'un appel système sans la contrainte de faire un autre appel
système visant à reconfigurer Syscall User Dispatch. Cette variable de contrôle peut être
positionnée soit sur SYSCALL_DISPATCH_FILTER_BLOCK pour empêcher les appels système de s'exécuter,
soit sur SYSCALL_DISPATCH_FILTER_ALLOW pour les autoriser temporairement à s'exécuter. Cette
valeur est vérifiée par le noyau à chaque nouvelle entrée d'un appel système et toute valeur
inattendue provoquera un SIGSYS insaisissable à cet instant, ce qui tuera l'application.
Lorsqu'un appel système est intercepté, le noyau envoie un signal SIGSYS adressé au thread
différé. Divers champs seront définis dans la structure siginfo_t (voir sigaction(2)) associée au
signal :
- si_signo contiendra SIGSYS.
- si_call_addr affichera l'adresse de l'instruction de l'appel système.
- si_syscall et si_arch indiqueront l'appel système qui a été tenté.
- si_code contiendra SYS_USER_DISPATCH.
- si_errno sera positionné à 0.
Le compteur du programme sera comme si l'appel système se produisait (c'est-à-dire que le compteur
du programme ne pointera pas vers l'instruction de l'appel système).
Quand le gestionnaire de signal rend la main au noyau, l'appel système se termine immédiatement et
rend la main au thread appelant, sans être réellement exécuté. Si nécessaire (c'est-à-dire lors de
l'émulation de l'appel système dans l'espace utilisateur), le gestionnaire de signal doit
positionner le code de retour de l'appel système sur une valeur adéquate, en modifiant le contexte
du registre stocké dans le paramètre ucontext du gestionnaire de signal. Voir sigaction(2),
sigreturn(2) et getcontext(3) pour plus d'informations.
Si arg2 est positionné sur PR_SYS_DISPATCH_OFF, Syscall User Dispatch est désactivé pour ce
thread. Les autres arguments doivent être positionnés à 0.
Le paramètre n'est pas préservé à travers un fork(2), un clone(2) ou un execve(2).
Pour plus d'informations, consultez le fichier Documentation/admin-guide/syscall-user-dispatch.rst
dans les sources du noyau.
PR_SET_TAGGED_ADDR_CTRL (depuis Linux 5.4, seulement sur arm64)
Contrôler la gestion du passage d'adresses labellisées de l'espace utilisateur au noyau
(c'est-à-dire des adresses où les bits 56—63 ne valent pas 0).
Le niveau de prise en charge est sélectionné par arg2, qui peut prendre une des valeurs
suivantes :
0 Les adresses qui sont passées pour être déréférencées par le noyau doivent être non
labellisées.
PR_TAGGED_ADDR_ENABLE
Les adresses qui sont passées pour être déréférencées par le noyau doivent être
labellisées, sauf celles résumées ci-dessous.
Les autres arguments arg3, arg4 et arg5 doivent être nuls.
En cas de succès, le mode indiqué dans arg2 est positionné sur le thread appelant et le code de
retour est 0. Si les paramètres ne sont pas valables, le mode indiqué dans arg2 n'est pas reconnu,
ou si la fonctionnalité n'est pas prise en charge par le noyau ou bien si elle est désactivée à
l'aide de /proc/sys/abi/tagged_addr_disabled, l'appel échoue avec l'erreur EINVAL.
En particulier, si prctl(PR_SET_TAGGED_ADDR_CTRL, 0, 0, 0, 0) échoue avec EINVAL, toutes les
adresses transmises au noyau doivent être non labellisées.
Indépendamment du mode défini, les adresses transmises à certaines interfaces doivent toujours
être non labellisées :
- brk(2), mmap(2), shmat(2), shmdt(2) et le paramètre new_address de mremap(2).
(avant Linux 5.6, ils acceptaient les adresses labellisées mais cela peut entraîner un
comportement non prévu. Ne vous y fiez pas).
- Les interfaces « polymorphic » (polymorphes) qui acceptent les pointeurs vers des types
arbitraires changent à void * ou un autre type générique, en particulier prctl(), ioctl(2) et
généralement setsockopt(2) (seules certaines options spécifiques de setsockopt(2) acceptent les
adresses labellisées).
Cette liste d'exceptions peut diminuer au fil des versions du noyau. Si le noyau peut garantir une
rétrocompatibilité, les effets de la transmission d'adresses labellisées à ces interfaces ne sont
pas spécifiés pour les nouveaux logiciels.
Le mode défini par cet appel est récupéré à travers fork(2) et clone(2). Le mode est remis à 0 par
execve(2) (c'est-à-dire les adresses labellisées ne sont pas autorisées dans l'ABI de
l'utilisateur ou du noyau).
Pour plus d'informations, consultez le fichier Documentation/arm64/tagged-address-abi.rst dans les
sources du noyau.
Attention : cet appel est d'abord conçu pour une utilisation par un environnement d'exécution. Un
appel PR_SET_TAGGED_ADDR_CTRL réussi peut, ailleurs, faire planter le processus appelant. Les
conditions pour une utilisation sûre sont complexes et dépendantes du système. Ne l'utilisez pas
sauf si vous savez ce que vous faites.
PR_GET_TAGGED_ADDR_CTRL (depuis Linux 5.4, seulement sur arm64)
Renvoyer le mode d'adressage étiqueté actuel du thread appelant.
Les paramètres arg2, arg3, arg4 et arg5 doivent être nuls.
Si les paramètres ne sont pas valables ou si cette fonctionnalité est désactivée ou non prise en
charge par le noyau, l'appel échoue avec EINVAL. En particulier, si prctl(PR_GET_TAGGED_ADDR_CTRL,
0, 0, 0, 0) échoue avec EINVAL, cette fonction n'est clairement pas prise en charge ou désactivée
avec /proc/sys/abi/tagged_addr_disabled. Dans ce cas, toutes les adresses transmises au noyau
doivent être non labellisées.
Sinon, l'appel renvoie une valeur non négative décrivant le mode d'adressage labellisé actuel,
encodé de la même manière que le paramètre arg2 de PR_SET_TAGGED_ADDR_CTRL.
Pour plus d'informations, consultez le fichier Documentation/arm64/tagged-address-abi.rst dans les
sources du noyau.
PR_TASK_PERF_EVENTS_DISABLE (depuis Linux 2.6.31)
Désactiver tous les compteurs de performance attachés au processus appelant, indépendamment du
fait que ces compteurs ont été créés par ce processus ou par un autre. Les compteurs de
performance créés par le processus appelant pour d'autres processus ne sont pas concernés. Pour
plus d'informations sur les compteurs de performance, consultez le fichier tools/perf/design.txt
des sources du noyau Linux.
Initialement appelé PR_TASK_PERF_COUNTERS_DISABLE. Renommé (avec la même valeur numérique) dans
Linux 2.6.32.
PR_TASK_PERF_EVENTS_ENABLE (depuis Linux 2.6.31)
L'inverse de PR_TASK_PERF_EVENTS_DISABLE. Activer les compteurs de performance attachés au
processus appelant.
Initialement appelé PR_TASK_PERF_COUNTERS_ENABLE. Renommé dans Linux 2.6.32.
PR_SET_THP_DISABLE (depuis Linux 3.15)
Affecter l'état de l'attribut « THP disable » pour le thread appelant. Si arg2 a une valeur
différente de zéro, l'attribut est activé ; dans le cas contraire, il est désactivé. L'utilisation
de cet attribut fournit un moyen de supprimer les pages de très grande taille correspondant à des
travaux pour lesquels le code ne peut pas être modifié, et dans les cas où le recours à des
routines malloc associées à des appels madvise(2) n'offre pas de solution (c'est-à-dire pour des
données allouées statiquement). L'activation de l'attribut « THP disable » est transmis aux
enfants créés au moyen de fork(2) et est conservé lors d'un appel à execve(2).
PR_GET_THP_DISABLE (depuis Linux 3.15)
Renvoyer (en résultat de fonction) le réglage actuel de l'attribut « THP disable » du thread
appelant, c'est à dire 1 si l'attribut est activé et 0 dans le cas contraire.
PR_GET_TID_ADDRESS (depuis Linux 3.5)
Renvoyer l'adresse clear_child_tid configurée par set_tid_address(2) et par l'attribut
CLONE_CHILD_CLEARTID de clone(2), à l'emplacement vers lequel pointe (int **) arg2. Cette option
n'est disponible que si le noyau est construit avec l'option CONFIG_CHECKPOINT_RESTORE. Notez que
comme l'appel système prctl() n'a pas d'implémentation compatible pour les ABI AMD64 x32 et MIPS
n32, et comme le noyau écrit un pointeur en utilisant la taille du pointeur du noyau, cette
opération attend un tampon en espace utilisateur de 8 octets (et non 4) sur ces ABI.
PR_SET_TIMERSLACK (depuis Linux 2.6.28)
Chaque thread comporte deux valeurs de temporisation relâchée : une valeur « default » et une
valeur « current ». Cette opération positionne la valeur « current » du temporisateur du thread
appelant. arg2 est un entier long non signé, la valeur « current » maximale est donc ULONG_MAX et
celle minimale est 1. Si la valeur en nanoseconde fournie dans arg2 est supérieure à zéro, la
valeur « current » est positionnée sur cette valeur. Si arg2 est égal à zéro, la temporisation
« current » est réinitialisée à la valeur « default » du thread.
La valeur « current » (actuelle) de temporisation relâchée est utilisée par le noyau pour grouper
les délais d'expiration des threads appelants qui sont proches les uns des autres. Par conséquent,
les délais d'expiration des threads pourraient être en retard jusqu'au nombre de nanosecondes
indiqué (mais jamais en avance). Le groupement des délais d'expiration permet de réduire la
consommation d'énergie du système en minimisant les réveils du processeur.
Les délais d'expiration affectés par la temporisation relâchée sont ceux définis par select(2),
pselect(2), poll(2), ppoll(2), epoll_wait(2), epoll_pwait(2), clock_nanosleep(2), nanosleep(2) et
futex(2) (et donc les fonctions de bibliothèque implémentées par futex, y compris
pthread_cond_timedwait(3), pthread_mutex_timedlock(3), pthread_rwlock_timedrdlock(3),
pthread_rwlock_timedwrlock(3) et sem_timedwait(3)).
La temporisation relâchée ne s'applique pas aux threads qui sont programmés avec une stratégie
d'ordonnancement en temps réel (consultez sched_setscheduler(2)).
Quand un nouveau thread est créé, les deux valeurs de temporisation relâchée sont rendues
identiques à la valeur « current » du thread qui l'a créé. Ensuite, un thread peut ajuster sa
valeur de temporisation relâchée « current » à l'aide de PR_SET_TIMERSLACK. La valeur « default »
ne peut pas être modifiée. Les valeurs de temporisation relâchée d'init (PID 1), l'ancêtre de tous
les processus, sont de 50 000 nanosecondes (50 microsecondes). Les valeurs de temporisation
relâchée sont transmises aux enfants créés avec fork(2) et sont préservées à travers execve(2).
Depuis Linux 4.6, la valeur « current » de temporisation relâchée d'un processus peut être
visualisée et modifiée à l'aide du fichier /proc/pid/timerslack_ns. Voir proc(5).
PR_GET_TIMERSLACK (depuis Linux 2.6.28)
Renvoyer (comme résultat de la fonction) la valeur « current » de temporisation relâchée du thread
appelant.
PR_SET_TIMING (depuis Linux 2.6.0)
Permettre de choisir la méthode de mesure du temps du processus à utiliser, en passant dans arg2
soit PR_TIMING_STATISTICAL (méthode statistique traditionnelle) ou PR_TIMING_TIMESTAMP (méthode
exacte utilisant des horodatages). PR_TIMING_TIMESTAMP n'est pas implémenté pour l'instant
(l'utilisation de ce mode renverra l'erreur EINVAL).
PR_GET_TIMING (depuis Linux 2.6.0)
Renvoyer (en résultat de fonction) quelle méthode de mesure du temps du processus est utilisée
actuellement.
PR_SET_TSC (depuis Linux 2.6.26, seulement sur x86)
Configurer l'état de l'attribut qui indique si le compteur d'horodatage peut être lu par le
processus. Utiliser PR_TSC_ENABLE pour arg2 permet d'autoriser les lectures ou PR_TSC_SIGSEGV pour
produire un SIGSEGV quand le processus essaie de lire le compteur d'horodatage.
PR_GET_TSC (depuis Linux 2.6.26, seulement sur x86)
Renvoyer, dans l'emplacement vers lequel pointe (int *) arg2, l'état de l'attribut qui indique si
le compteur d'horodatage peut être lu.
PR_SET_UNALIGN
(Seulement sur : ia64, depuis Linux 2.3.48 ; parisc, depuis Linux 2.6.15 ; PowerPC, depuis
Linux 2.6.18 ; Alpha, depuis Linux 2.6.22 ; sh, depuis Linux 2.6.34 ; tile, depuis Linux 3.12).
Définir les bits de contrôle pour les accès non alignés à arg2. La valeur PR_UNALIGN_NOPRINT
signifie que les accès non alignés en espace utilisateur sont silencieusement corrigés, et
PR_UNALIGN_SIGBUS cause l'envoi de SIGBUS lors d'un accès utilisateur non aligné. Alpha gère aussi
un attribut supplémentaire dont la valeur est 4 et qui n'a pas de constante correspondante nommée,
qui demande au noyau de corriger les accès non alignés (il revient à utiliser l'attribut UAC_NOFIX
dans l'opération SSI_NVPAIRS de l'appel système setsysinfo() sur Tru64).
PR_GET_UNALIGN
(Consultez PR_SET_UNALIGN pour les informations sur les versions et les architectures). Renvoyer
les bits de contrôle des accès non alignés dans l'emplacement vers lequel pointe (unsigned int *)
arg2.
PR_GET_AUXV (depuis Linux 6.4)
Récupérer le vecteur auxiliaire (auxv) dans le tampon vers lequel pointe (void *) arg2 et dont la
longueur est donnée par arg3. Si le tampon n'est pas suffisamment long pour le vecteur auxiliaire
complet, la copie sera tronquée. Renvoyer (comme résultat de la fonction) la longueur totale du
vecteur auxiliaire. arg4 et arg5 doivent être 0.
PR_SET_MDWE (depuis Linux 6.3)
Configurer le masque de protection « Memory-Deny-Write-Execute » (MDWE) du processus appelant. Une
fois les bits de protection définis, ils ne peuvent plus être modifiés. arg2 doit être un masque
de bits de :
PR_MDWE_REFUSE_EXEC_GAIN
Les nouvelles protections de mappage mémoire ne peuvent pas être accessibles en écriture et
exécutables. Les mappages non exécutables ne peuvent pas devenir exécutables.
PR_MDWE_NO_INHERIT (depuis Linux 6.6)
Ne pas propager la protection MDWE aux processus enfant sur fork(2). Définir ce bit
nécessite de définir également PR_MDWE_REFUSE_EXEC_GAIN.
PR_GET_MDWE (depuis Linux 6.3)
Renvoyer (comme résultat de la fonction) le masque de protection « Memory-Deny-Write-Execute » du
processus appelent. Consultez PR_SET_MDWE pour des informations sur les bits de masque de
protection.
VALEUR RENVOYÉE
En cas de réussite, PR_CAP_AMBIENT+PR_CAP_AMBIENT_IS_SET, PR_CAPBSET_READ, PR_GET_DUMPABLE,
PR_GET_FP_MODE, PR_GET_IO_FLUSHER, PR_GET_KEEPCAPS, PR_MCE_KILL_GET, PR_GET_NO_NEW_PRIVS,
PR_GET_SECUREBITS, PR_GET_SPECULATION_CTRL, PR_SVE_GET_VL, PR_SVE_SET_VL, PR_GET_TAGGED_ADDR_CTRL,
PR_GET_THP_DISABLE, PR_GET_TIMING, PR_GET_TIMERSLACK, PR_GET_AUXV et (s'il rend la main) PR_GET_SECCOMP
renvoient les valeurs positives décrites ci-dessus. Toute autre valeur d'op renvoie 0 en cas de succès.
En cas d'erreur, -1 est renvoyé et errno est positionné pour indiquer l'erreur.
ERREURS
EACCES op vaut PR_SET_SECCOMP et arg2 vaut SECCOMP_MODE_FILTER, mais le processus n'a pas la capacité
CAP_SYS_ADMIN ou n'a pas positionné l'attribut no_new_privs (voir le point sur PR_SET_NO_NEW_PRIVS
ci-dessus).
EACCES op vaut PR_SET_MM, et arg3 vaut PR_SET_MM_EXE_FILE, le fichier n'est pas exécutable.
EBADF op vaut PR_SET_MM, arg3 vaut PR_SET_MM_EXE_FILE, et le descripteur de fichier passé dans le
paramètre arg4 n'est pas valable.
EBUSY op vaut PR_SET_MM, arg3 vaut PR_SET_MM_EXE_FILE, et il s'agit de la seconde tentative de
modification du lien symbolique /proc/pid/exe, ce qui n'est pas autorisé.
EFAULT arg2 est une adresse non valable.
EFAULT op vaut PR_SET_SECCOMP, arg2 vaut SECCOMP_MODE_FILTER, le système a été construit avec
CONFIG_SECCOMP_FILTER et arg2 n'est pas une adresse valable.
EFAULT op vaut PR_SET_SYSCALL_USER_DISPATCH et arg5 a une adresse non valable.
EINVAL La valeur de op n'est pas reconnue ou n'est pas prise en charge sur ce système.
EINVAL op vaut PR_MCE_KILL, PR_MCE_KILL_GET ou PR_SET_MM, et les paramètres non utilisés de prctl() n'ont
pas été réglés à zéro.
EINVAL arg2 n'est pas une valeur valable pour cette op.
EINVAL op vaut PR_SET_SECCOMP ou PR_GET_SECCOMP et le noyau n'a pas été configuré avec CONFIG_SECCOMP.
EINVAL op vaut PR_SET_SECCOMP, arg2 vaut SECCOMP_MODE_FILTER et le noyau n'a pas été configuré avec
CONFIG_SECCOMP_FILTER.
EINVAL op vaut PR_SET_MM, et l'une des assertions suivantes est vraie :
- arg4 ou arg5 est différent de 0 ;
- arg3 est strictement plus grand que TASK_SIZE (la limite sur la taille de l'espace d'adressage
utilisateur pour cette architecture) ;
- arg2 vaut PR_SET_MM_START_CODE, PR_SET_MM_END_CODE, PR_SET_MM_START_DATA, PR_SET_MM_END_DATA ou
PR_SET_MM_START_STACK, et les permissions pour la zone de mémoire correspondante ne satisfont
pas les conditions requises ;
- arg2 vaut PR_SET_MM_START_BRK ou PR_SET_MM_BRK, et arg3 est inférieur ou égal à la fin du
segment de données, ou indique une valeur qui causerait le dépassement de la limite de
ressource RLIMIT_DATA.
EINVAL op vaut PR_SET_PTRACER et arg2 ne vaut ni 0, ni PR_SET_PTRACER_ANY, ni le PID d'un processus
existant.
EINVAL op vaut PR_SET_PDEATHSIG et arg2 n'est pas un numéro de signal valable.
EINVAL op vaut PR_SET_DUMPABLE et arg2 ne vaut ni SUID_DUMP_DISABLE, ni SUID_DUMP_USER.
EINVAL op vaut PR_SET_TIMING et arg2 n'a pas la valeur PR_TIMING_STATISTICAL.
EINVAL op vaut PR_SET_NO_NEW_PRIVS et arg2 ne vaut pas 1, ou arg3, arg4 ou arg5 est différent de zéro.
EINVAL op vaut PR_GET_NO_NEW_PRIVS et arg2, arg3, arg4 ou arg5 est différent de zéro.
EINVAL op vaut PR_SET_THP_DISABLE et arg3, arg4 ou arg5 est différent de zéro.
EINVAL op vaut PR_GET_THP_DISABLE et arg2, arg3, arg4 ou arg5 est différent de zéro.
EINVAL op vaut PR_CAP_AMBIENT et un paramètre inutilisé (arg4, arg5 ou, dans le cas de
PR_CAP_AMBIENT_CLEAR_ALL, arg3) ne vaut pas zéro ; ou bien arg2 a une valeur non valable ; ou arg2
vaut PR_CAP_AMBIENT_LOWER, PR_CAP_AMBIENT_RAISE ou PR_CAP_AMBIENT_IS_SET et arg3 n'indique pas de
capacité valable.
EINVAL op vaut PR_SET_SPECULATION_CTRL ou PR_SET_SPECULATION_CTRL et des paramètres inutilisés de prctl()
ne valent pas 0.
EINVAL op vaut PR_PAC_RESET_KEYS et les paramètres ne sont pas valables ou ne sont pas pris en charge.
Voir la description de PR_PAC_RESET_KEYS ci-dessus pour des détails.
EINVAL op vaut PR_SVE_SET_VL et les paramètres ne sont pas valables ou ne sont pas pris en charge, ou
bien SVE n'est pas disponible sur cette plateforme. Voir la description de PR_SVE_SET_VL ci-dessus
pour des détails.
EINVAL op vaut PR_SVE_GET_VL et SVE n'est pas disponible sur cette plateforme.
EINVAL op vaut PR_SET_SYSCALL_USER_DISPATCH et l'une des assertions suivantes est vraie :
- arg2 vaut PR_SYS_DISPATCH_OFF et les autres paramètres ne sont pas à 0 ;
- arg2 vaut PR_SYS_DISPATCH_ON et la plage de mémoire indiquée dépasse l'espace d'adressage du
processus.
- arg2 n'est pas valable.
EINVAL op vaut PR_SET_TAGGED_ADDR_CTRL et les paramètres ne sont pas valables ou ne sont pas pris en
charge. Voir la description de PR_SET_TAGGED_ADDR_CTRL ci-dessus pour des détails.
EINVAL op vaut PR_GET_TAGGED_ADDR_CTRL et les paramètres ne sont pas valables ou ne sont pas pris en
charge. Voir la description de PR_GET_TAGGED_ADDR_CTRL pour des détails.
ENODEV op vaut PR_SET_SPECULATION_CTRL et le noyau ou le processeur ne gère pas la fonction défectueuse
de spéculation demandée.
ENXIO op vaut PR_MPX_ENABLE_MANAGEMENT ou PR_MPX_DISABLE_MANAGEMENT et le noyau ou le processeur ne
prennent pas en charge la gestion de MPX. Vérifiez que le noyau et le processeur gèrent le MPX.
ENXIO opt vaut PR_SET_SPECULATION_CTRL, impliquant que le contrôle de la fonction défectueuse de
spéculation sélectionnée n'est pas possible. Voir les champs de bit de PR_GET_SPECULATION_CTRL
pour savoir les options disponibles.
EOPNOTSUPP
op vaut PR_SET_FP_MODE et arg2 a une valeur non prise en charge ou non valable.
EPERM op vaut PR_SET_SECUREBITS et l'appelant n'a pas la capacité CAP_SETPCAP, a essayé d'enlever un
attribut de « verrouillage » ou a essayé de positionner un attribut pour lequel l'attribut de
verrouillage était positionné (consultez capabilities(7)).
EPERM op vaut PR_SET_SPECULATION_CTRL alors que la spéculation est désactivée avec PR_SPEC_FORCE_DISABLE
et l'appelant a essayé de la réactiver.
EPERM op vaut PR_SET_KEEPCAPS et l'attribut SECBIT_KEEP_CAPS_LOCKED de l'appelant est positionné
(consultez capabilities(7)).
EPERM op vaut PR_CAPBSET_DROP et l'appelant n'a pas la capacité CAP_SETPCAP.
EPERM op vaut PR_SET_MM et l'appelant n'a pas la capacité CAP_SYS_RESOURCE.
EPERM op vaut PR_CAP_AMBIENT et arg2 vaut PR_CAP_AMBIENT_RAISE, mais soit la capacité indiquée dans arg3
n'est pas présente dans les capacités autorisées et récupérables du processus, ou bien le bit de
sécurité PR_CAP_AMBIENT_LOWER a été positionné.
ERANGE op vaut PR_SET_SPECULATION_CTRL et arg3 ne vaut ni PR_SPEC_ENABLE, ni PR_SPEC_DISABLE, ni
PR_SPEC_FORCE_DISABLE, ni PR_SPEC_DISABLE_NOEXEC.
VERSIONS
IRIX dispose d'un appel système prctl() (également introduit dans Linux 2.1.44 sur l'architecture MIPS
sous le nom irix_prctl), dont le prototype est
ptrdiff_t prctl(int op, int arg2, int arg3);
et les opérations permettent de d'obtenir le nombre maximal de processus par utilisateur, d’obtenir le
nombre maximal de processeurs utilisables par un processus, de vérifier si un processus est bloqué,
d’obtenir ou de définir la taille maximale de la pile, etc.
STANDARDS
Linux.
HISTORIQUE
Linux 2.1.57, glibc 2.0.6
VOIR AUSSI
signal(2), core(5)
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud
<tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard
<fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau
<jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François
<nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard
<simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot
<david@tilapin.org>, Cédric Boutillier <cedric.boutillier@gmail.com>, Frédéric Hantrais
<fhantrais@gmail.com> et Jean-Philippe MENGUAL <jpmengual@debian.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les conditions de copie et de
distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
⟨debian-l10n-french@lists.debian.org⟩.