Man page - pkeys(7)

Packages contains this manual

Package: manpages
apt-get install manpages

Manuals in package:

Documentations in package:

manpages

Available languages:

en fr ru ro

Manual

pkeys

NOM
DESCRIPTION
Comportement du gestionnaire de signal
Appels système des clés de protection
EXEMPLES
Source du programme
VOIR AUSSI
TRADUCTION

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 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 .