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 journalctlque le message s'affiche 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, est-il possible de le résoudre?

Edit: utiliser linux-image-4.15.0-3-amd64au lieu de linux-image-4.16.0-1-amd64travaux, mais je ne veux pas utiliser un noyau plus ancien.

Ressemble à certains composants de vos blocs système tout en essayant d'obtenir des données aléatoires du noyau (c'est-à-dire en lisant /dev/urandomou 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 l'a souligné Bigon dans sa 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 = 43838a23a05fbd13e47d750d3dfd77001536dd33

Ce changement affecte par inadvertance urandom_read, entraînant le traitement de l'état crng_init == 1 comme non initialisé et le blocage d'urandom, malgré le fait que cet état existe spécifiquement pour prendre en charge les besoins non cryptographiques au démarrage: https://git.kernel.org/pub /scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1863

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 )

... Pourtant, vous pouvez essayer d'utiliser havegedou rng-toolsde récupérer 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 rng-tools5semble 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.

Exécuter apt-get install rng-toolscomme sudans le terminal devrait fonctionner.

rng-toolsn'aide que si votre système prend en charge le matériel pour les nombres aléatoires, comme la « clé sécurisée » d'Intel . Cette façon inventé avec Ivy Bridge . Mes systèmes avec des processeurs 1037u (basés sur ivy bridge) n'ont pas ce support matériel. N'aide donc rng-toolspas.

Sur un autre système ici avec un processeur de pont de sable i3, rng-toolsaidez- moi . Le rngdservice 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 rngdest connecté dans syslog.

Peut également se produire après la suppression de la partition de swap

Le blocage avant kernel: random: crng init donepeut é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/resume doit être complètement vide ou lu RESUME=. Supprimez tout numéro UUID. RESUME=NONEn'est pas valide.

$ sudo vim /etc/initramfs-tools/conf.d/resume

Le système de fichiers RAM initial nécessite une mise à jour pour que ces modifications prennent effet:

$ sudo update-initramfs -u

Dans mon cas, j'exécutais une 4.19.0-4-amd64machine virtuelle Debian Buster (noyau ) sur Proxmox VE.

La solution était d'ajouter un appareil VirtIO RNG à la VM. Sur Proxmox, cela se fait en éditant le fichier de configuration VM .

Dans mon cas, j'ai édité /etc/pve/qemu-server/110.confet ajouté la ligne suivante:

args: -device virtio-rng-pci

Aucun outil de l'espace utilisateur (par exemple rng-toolsou haveged) n'était nécessaire.