Provided by: manpages-fr_4.23.1-1_all 
NOM
pkeys – Aperçu des clés de protection de la mémoire
DESCRIPTION
Les clés de protection de la mémoire (Memory Protection Keys — pkeys) sont une extension
des permissions de la mémoire basées sur les pages. Les permissions normales de page
nécessitent des appels système coûteux et des invalidations du TLB (Translation Lookaside
Buffer) lors de modifications de permission. Les clés de protection de la mémoire
fournissent un mécanisme pour changer les protections sans avoir besoin de modifier la
table des pages lors de chaque modification de permission.
Pour utiliser pkeys, le logiciel doit d’abord « étiqueter » une page dans la table des
pages avec une pkey. Une fois cette étiquette posée, une application a seulement à changer
le contenu d’un registre pour retirer l’accès en écriture ou tous les accès à une page
étiquetée.
Les clés de protection de la mémoire fonctionnent en conjonction avec les permissions
PROT_READ, PROT_WRITE et PROT_EXEC existantes passées aux appels système tels que
mprotect(2) et mmap(2), mais agissent toujours pour restreindre encore plus ces mécanismes
de permission traditionnels.
Si un processus réalise un accès qui enfreint les restrictions de pkey, il reçoit un
signal SIGSEGV. Consultez sigaction(2) pour des détails sur l’information disponible avec
ce signal.
Pour utiliser la fonctionnalité de pkeys, le processeur doit la prendre en charge et le
noyau doit contenir une prise en charge pour la fonctionnalité d’un processeur donné. Au
tout début de 2016, seuls les processeurs x86 d’Intel à venir étaient pris en charge et
ceux-ci géraient 16 clés de protection de la mémoire pour chaque processus. Cependant, la
pkey 0 est utilisée comme clé par défaut, donc un maximum de 15 sont disponibles pour une
utilisation effective d’application. La clé par défaut est affectée à n’importe quelle
région de la mémoire pour laquelle une pkey n’a pas été assignée explicitement à l’aide de
pkey_mprotect(2).
Les clés de protection ont la capacité d’ajouter une couche de sécurité et de fiabilité
aux applications, mais elles n’ont pas été conçues principalement pour une fonctionnalité
de sécurité. Par exemple, WRPKRU est une instruction entièrement non privilégiée, aussi
les pkeys sont inutiles dans tous les cas où un attaquant contrôle le registre PKRU ou
peut exécuter des instructions arbitraires.
Les applications doivent être très précautionneuses pour assurer de ne pas faire
« fuiter » leurs clés de protection. Par exemple, avant d’appeler pkey_free(2),
l’application doit être sûre qu’aucune mémoire a cette pkey assignée. Si l’application
laisse la pkey libérée assignée, un prochain utilisateur de cette pkey peut par
inadvertance modifier les permissions d’une structure de données étrangère, pouvant
impacter la sécurité ou la stabilité. Le noyau permet actuellement aux pkeys en cours
d’avoir pkey_free(2) appelée sur elles, car cela pourrait avoir des implications de
performance de processeur ou de mémoire pour réaliser des vérifications supplémentaires
nécessaires pour désactiver cet appel. L’implémentation des vérifications nécessaires est
laissée aux applications. Celles-ci peuvent mettre en œuvre ces vérifications en
parcourant le fichier /proc/pid/smaps pour des régions de la mémoire ayant la pkey
assignée. Plus de détails sont fournis dans proc(5).
Toute application voulant utiliser les clés de protection doivent être capables de
fonctionner sans elles. Elles peuvent être indisponibles parce que le matériel exécutant
cette application ne les prennent pas en charge, le code du noyau ne fournit aucune prise
en charge ou cette prise en charge a été désactivée, ou parce que les clés ont été
allouées, peut être par une bibliothèque utilisée par l’application. Il est recommandé aux
applications voulant utiliser les clés de protection de simplement appeler pkey_alloc(2)
et de tester si l’appel réussit au lieu d’essayer de détecter une prise en charge de la
fonctionnalité par tout autre moyen.
Quoique non nécessaire, la prise en charge matérielle des clés de protection peut être
déterminée à l’aide de l’instruction cpuid. La manière de réaliser cela est décrite dans
le manuel pour les développeurs de logiciels pour Intel. Le noyau réalise ce dénombrement
et expose cette information dans le champ « flags » de /proc/cpuinfo. La chaîne « pku »
dans ce champ indique la prise en charge matérielle des clés de protection et la chaîne
« ospke » indique que le noyau gère et active la prise en charge des clés de protection.
Les applications utilisant les threads et les clés de protection doivent être
particulièrement attentives. Les threads héritent des droits des clés de protection de
leur parent au moment de l’appel système clone(2). Les applications doivent aussi
s’assurer que leurs propres permissions sont appropriées pour les threads enfant au moment
de l’appel clone(2) ou de s’assurer que chaque thread enfant peut réaliser sa propre
initialisation des droits de clés de protection.
Comportement du gestionnaire de signal
Chaque fois qu’un gestionnaire de signal est invoqué (y compris pour les signaux
imbriqués), le thread obtient temporairement un nouvel ensemble par défaut de droits de
clés de protection qui outrepasse les droits du contexte interrompu. Cela signifie que les
applications doivent rétablir les droits désirés des clés de protection lors de
l’utilisation d’un gestionnaire de signal si ces droits différent de ceux par défaut. Les
droits de n’importe quel contexte sont restaurés lors du renvoi du gestionnaire de signal.
Ce comportement de signal est inhabituel et est dû au fait que le registre PKRU x86 (qui
stocke les droits d’accès des clés de protection) est géré avec le même mécanisme matériel
(XSAVE) qui gère les registres de virgule flottante. Le comportement du signal est le même
que celui des registres de virgule flottante.
Appels système des clés de protection
Le noyau Linux met en œuvre les appels système suivants relatifs aux clés de protection :
pkey_mprotect(2), pkey_alloc(2) et pkey_free(2).
Les appels système de Linux pour pkey sont disponibles uniquement si le noyau a été
configuré et construit avec l’option CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS.
EXEMPLES
Le programme ci-dessous alloue une page de mémoire avec les permissions en lecture et
écriture. Puis il écrit quelques données dans la mémoire et les relit avec succès. Après
cela, il essaie d’allouer une clé de protection et désactive l’accès à la page en
utilisant l’instruction WRPKRU. Il essaie alors d’accéder à la page qui est supposée
provoquer un signal fatal pour l’application.
$ ./a.out
le buffer contient : 73
sur le point de lire le buffer de nouveau...
Segmentation fault (core dumped)
Source du programme
#define _GNU_SOURCE
#include <err.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
int
main(void)
{
int status;
int pkey;
int *buffer;
/*
* Allocation d’une page de mémoire.
*/
buffer = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
if (buffer == MAP_FAILED)
err(EXIT_FAILURE, "mmap");
/*
* Mise de données aléatoires dans la page (toujours OK à affecter).
*/
*buffer = __LINE__;
printf("le buffer contient : %d\n", *buffer);
/*
* Allocation d’une clé de protection :
*/
pkey = pkey_alloc(0, 0);
if (pkey == -1)
err(EXIT_FAILURE, "pkey_alloc");
/*
* Désactivation de l’accès à toute mémoire avec l’ensemble
* « pkey », même si aucun droit n’existe à ce moment.
*/
status = pkey_set(pkey, PKEY_DISABLE_ACCESS);
if (status)
err(EXIT_FAILURE, "pkey_set");
/*
* Mettre la clé de protection dans « buffer ».
* Noter que c’est toujours lect./écrit. aussi longtemps que mprotect()
* est concerné et que le pkey_set() précédent l’écrase.
*/
status = pkey_mprotect(buffer, getpagesize(),
PROT_READ | PROT_WRITE, pkey);
if (status == -1)
err(EXIT_FAILURE, "pkey_mprotect");
printf("sur le point de lire le buffer de nouveau...\n");
/*
* Cela va planter car l’accès a été désactivé.
*/
printf("le buffer contient : %d\n", *buffer);
status = pkey_free(pkey);
if (status == -1)
err(EXIT_FAILURE, "pkey_free");
exit(EXIT_SUCCESS);
}
VOIR AUSSI
pkey_alloc(2), pkey_free(2), pkey_mprotect(2), sigaction(2)
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> et Jean-Paul Guillonneau
<guillonneau.jeanpaul@free.fr>
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⟩.