Pourquoi ne puis-je pas écraser mon système avec une fourche piégée?

Récemment, j'ai déterré des informations sur les processus sous GNU / Linux et j'ai rencontré la fameuse bombe à fourche:

:(){ : | :& }; :

Théoriquement, il est supposé se dupliquer à l'infini jusqu'à ce que le système manque de ressources ...

Cependant, j'ai essayé de tester à la fois sur une distribution CLI Debian et une distribution graphique Mint , et cela ne semble pas avoir beaucoup d'incidence sur le système. Oui, il y a des tonnes de processus qui sont créés, et après un moment, je lis dans la console des messages tels que:

bash: fork: ressource temporairement indisponible

bash: fork: réessayer: aucun processus enfant

Mais après un certain temps, tous les processus sont tués et tout retourne à la normale. J'ai lu que la commande ulimit définissait un nombre maximal de processus par utilisateur, mais je ne parais pas être en mesure de l'augmenter vraiment.

Quelles sont les protections système contre les bombes à la fourche? Pourquoi ne se reproduit-il pas jusqu'à ce que tout soit gelé ou au moins beaucoup décalé? Y a-t-il un moyen de vraiment écraser un système avec une bombe fourchue?

Vous avez probablement une distribution Linux qui utilise systemd.

Systemd crée un groupe de contrôle pour chaque utilisateur, et tous les processus d'un utilisateur appartiennent au même groupe de contrôle.

Cgroups est un mécanisme Linux permettant de définir des limites sur les ressources système, telles que le nombre maximal de processus, les cycles de processeur, l'utilisation de la mémoire vive, etc. Il s'agit d'une couche de limitation des ressources différente, plus moderne que celle ulimit(qui utilise l'appel getrlimit()système).

Si vous exécutez systemctl status user-<uid>.slice(qui représente le groupe de contrôle de l'utilisateur), vous pouvez voir le nombre actuel et maximal de tâches (processus et threads) autorisés dans ce groupe de contrôle.

$ systemctl status user- $ UID.slice
● user-22001.slice - Tranche d'utilisateur de l'UID 22001
   Chargé: chargé
  Drop-In: /usr/lib/systemd/system/user-.slice.d
           └─10-defaults.conf
   Actif: Actif depuis lun. 2018-09-10 17:36:35 EEST; Il y a 1 semaines 3 jours
    Tâches: 17 (limite: 10267)
   Mémoire: 616,7 M

Par défaut, le nombre maximal de tâches que systemd autorisera pour chaque utilisateur correspond à 33% du "maximum du système" ( sysctl kernel.threads-max); cela équivaut généralement à environ 10 000 tâches. Si vous voulez changer cette limite:

• Dans Systemd v239 et versions ultérieures, la valeur par défaut de l'utilisateur est définie via TasksMax = dans:

  /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
  

  Pour ajuster la limite pour un utilisateur spécifique (qui sera appliqué immédiatement ainsi que stocké dans /etc/systemd/system.control), exécutez:

  systemctl [--runtime] set-property user-<uid>.slice TasksMax=<value>
  

  Les mécanismes habituels de substitution des paramètres d'une unité (tels que systemctl edit) peuvent également être utilisés ici, mais ils nécessiteront un redémarrage. Par exemple, si vous souhaitez modifier la limite pour chaque utilisateur, vous pouvez créer /etc/systemd/system/user-.slice.d/15-limits.conf.

• Dans Systemd v238 et versions antérieures, les paramètres utilisateur par défaut sont définis via UserTasksMax = in /etc/systemd/logind.conf. Changer la valeur nécessite généralement un redémarrage.

Plus d'informations à ce sujet:

• man 5 systemd.resource-control
• man 5 systemd.slice
• man 5 logind.conf
• http://0pointer.de/blog/projects/systemd.html (recherchez cette page dans cgroups)
• man 7 cgroups et https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
• https://en.wikipedia.org/wiki/Cgroups

Cela ne plantera plus les systèmes Linux modernes de toute façon.

Il crée une horde de processus mais ne brûle pas vraiment autant de ressources processeur, car les processus deviennent inactifs. Vous manquez de logements dans la table de processus avant de manquer de RAM maintenant.

Si Hkoof ne vous limite pas, c’est la modification suivante qui réduit les systèmes:

:(){ : | :& : | :& }; :

Dans les années 90, j'en ai accidentellement déclenché une. J'avais par inadvertance défini le bit d'exécution sur un fichier source C contenant une commande fork (). Quand j'ai double-cliqué dessus, csh a essayé de l'exécuter plutôt que de l'ouvrir dans un éditeur comme je le voulais.

Même à ce moment-là, le système n'a pas été bloqué. Unix est suffisamment robuste pour que votre compte et / ou le système d'exploitation ait une limite de processus. Ce qui se produit à la place est que cela devient extrêmement lent et que tout ce qui doit démarrer un processus est susceptible d’échouer.

En coulisse, la table des processus se remplit de processus qui essaient de créer de nouveaux processus. Si l'un d'entre eux se termine (soit en raison d'une erreur sur le fork, parce que la table de processus est pleine, soit à cause d'un opérateur désespéré qui tente de rétablir l'intégrité de son système), l'un des autres processus en lancera un nouveau à remplir. le vide.

La "bombe à la bombe" est fondamentalement un système de processus involontairement auto-réparateur dans le but de garder votre table de processus complète. La seule façon de l'arrêter est de les tuer tous en même temps.