Lorsque je me connecte, il se bloque jusqu'à ce que crng init soit terminé
Lorsque je me connecte avec LightDM sur mon ordinateur portable exécutant Debian Unstable, il a récemment commencé à se bloquer pendant environ 2 minutes jusqu'à ce que journalctl affiche le message kernel: random: crng init done. Lorsque j'appuie sur des touches aléatoires de mon clavier pendant qu'il se bloque, il se connecte plus rapidement (environ 10 secondes). Avant de ne pas avoir ce problème, existe-t-il un moyen de le résoudre?
Modifier: à l'aide de linux-image-4.15.0-3-AMD64 au lieu de linux-image-4.16.0-1-AMD64 fonctionne, mais je ne veux pas utiliser un noyau plus ancien.
Ressemble à un composant de vos blocs système tout en essayant d'obtenir des données aléatoires du noyau (c'est-à-dire en lisant /dev/urandom Ou en appelant getrandom()) en raison d'une entropie insuffisante (caractère aléatoire) disponible.
Je n'ai pas d'explication prête pour expliquer pourquoi le problème dépend d'une version particulière du noyau, ou du composant de votre système qui bloque réellement, mais quelle que soit la cause racine,
En effet, comme souligné par Bigon dans son réponse , il semble s'agir d'un bug du noyau introduit en 4.16:
Ce bogue est introduit par le changement de "crng_init> 0" à "crng_init> 1" dans ce commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux. git/commit /? id = 43838a23a05fbd13e47d750d3dfd77001536dd
Ce changement affecte par inadvertance urandom_read, provoquant l'état crng_init == 1 à être traité comme non initialisé et provoquant le blocage d'urandom, bien que cet état existe spécifiquement pour prendre en charge non - besoins cryptographiques au démarrage: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n186 =
Le rétablissement de 43838a23a05f ("random: fix crng_ready () test") corrige le bogue (testé avec 4.16.5-1), mais cela peut entraîner des problèmes de sécurité (CVE-2018-1108 est mentionné dans 43838a23a05f). Je teste un correctif plus localisé qui devrait être plus acceptable en amont.
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82 )
... Néanmoins, vous pouvez essayer d'utiliser haveged ou rng-tools pour recueillir l'entropie plus rapidement.
C'est un changement (bug?) Dans le noyau, voir: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572
Pour atténuer cette installation de rng-tools5 semble aider. Notez que je ne sais pas si l'installation de ce package a un impact ou non sur la génération de clés de cryptographie forte
Edit: Apparemment, la mise à jour d'util-linux 2.32 devrait résoudre le problème
C'est un bug du noyau qui peut se produire avec différents noyaux.
Fonctionnement apt-get install rng-tools comme su dans le terminal devrait fonctionner.
rng-tools n'aide que si votre système prend en charge le matériel pour les nombres aléatoires, comme " Secure Key d'Intel ". De cette façon inventé avec Ivy Bridge . Mes systèmes avec des processeurs 1037u (basés sur ivy bridge) ont pas ce support matériel. Par conséquent rng-tools n'aide pas.
Sur un autre système ici avec un processeur Sandy Bridge i3 rng-tools aidez. Le service rngd doit être démarré très tôt dans le processus de démarrage, afin de remplir la file d'attente d'entropie. C'est le cas dans la séquence de démarrage avec Ubuntu, je ne sais pas si cela est vrai pour les autres distributions, mais vous pouvez le découvrir, car le début de rngd est connecté dans syslog.
Peut également se produire après la suppression de la partition de swap
Suspendu avant kernel: random: crng init done peut également se produire après la suppression d'une partition de swap.
Si une partition de swap est supprimée, le fichier de configuration /etc/initramfs-tools/conf.d/resumedoit être complètement vide ou lire RESUME=. Supprimez tout numéro UUID. RESUME=NONE n'est pas valide.
$ Sudo vim /etc/initramfs-tools/conf.d/resume
Le système de fichiers initial RAM nécessite une mise à jour pour que ces modifications prennent effet:
$ Sudo update-initramfs -u
Dans mon cas, j'exécutais un Debian Buster (kernel 4.19.0-4-AMD64) VM sur Proxmox VE.
La solution consistait à ajouter un appareil VirtIO RNG à la machine virtuelle. Sur Proxmox, cela se fait en éditant le fichier de configuration VM .
Dans mon cas, j'ai édité /etc/pve/qemu-server/110.conf et a ajouté la ligne suivante:
args: -device virtio-rng-pci
Aucun outil d'espace utilisateur (par exemple rng-tools ou haveged) étaient nécessaires.