Qu'est-ce qui mange mon entropie? Ou que montre vraiment entropy_avail?

Question

Voici des graphiques avec la valeur de /proc/sys/kernel/random/entropy_avail sur un Raspberry Pi. Cette réponse ^{ce qui n'est peut-être pas correct} le décrit comme:

/proc/sys/kernel/random/entropy_avail vous donne simplement le nombre de bits qui peuvent actuellement être lus à partir de /dev/random. Les tentatives de lire plus que cela bloqueront jusqu'à ce que plus d'entropie soit disponible.

Le motif présente toujours le même motif de scie "stable" avec une diminution de ~ 130 bits toutes les minutes. Si l'entropie croît trop, quelque chose "la mange" pour revenir à la gamme 700-800. Si je redémarre l'appareil, l'entropie est toujours consommée chaque minute, mais en plus petits morceaux, ce qui lui permet de repousser à une plage de 700 à 800.

Comment dois-je interpréter les graphiques? Que se passe-t-il?

Mon sentiment est que s'il n'y avait qu'un processus utilisant un générateur de nombres aléatoires, le entropy_avail une fois déséquilibré (en utilisant le matériel de l'appareil) devrait augmenter à l'infini ou diminuer au niveau de 200, lorsque /dev/random arrêterait de fournir les valeurs.

De plus, si l'une des méthodes de surveillance (voir les contrôles ci-dessous) a influencé l'entropie, elle devrait plutôt diminuer l'entropie toutes les secondes, plutôt que de la laisser croître et chuter soudainement à des intervalles d'une minute.

^{(si je laisse la machine inactive, le modèle de "scie" stable continue pendant des jours, j'ai pris les captures d'écran dans un court laps de temps)}

Les graphiques

La machine est inactive depuis longtemps:
Vers 19:14:45, une autre machine a accédé à apt-cacher sur le Pi - l'entropie a augmenté (je suppose de l'utilisation du réseau). Après cela, à 19:16:30, la baisse aux "niveaux habituels" était plus importante que d'habitude (elle est également reproductible - si entropy_avail devient trop grand, il chute plus vite):
Je redémarre la machine, l'entropie croît jusqu'à atteindre le niveau "habituel":
Encore une fois, il atteint un état inactif:
Après un autre redémarrage, le moment de la diminution de l'entropie change, mais cela se produit toujours toutes les minutes:

Chèques

J'ai arrêté netdata (programme de surveillance) et vérifié avec watch -n1 cat /proc/sys/kernel/random/entropy_avail. La valeur de entropy_avail augmente à ~ 800 et chute à ~ 680 à intervalles réguliers d'une minute.
Par conseil " tracez tous les processus pour accéder à/dev/random et/dev/urandom" J'ai vérifié avec inotifywait (idée d'un réponse à une question similaire ) sur Debian VM et il n'y a aucun accès à /dev/random ou /dev/urandom en ce moment entropy_avail drops (bien sûr, la vérification manuelle enregistre l'événement).
J'ai utilisé entropy-watcher pour vérifier l'entropie comme déconseillé d'utiliser watch. Les résultats sont toujours cohérents avec une augmentation régulière et une forte baisse toutes les minutes:
```
833 (-62) 836 (+3) 838 (+2) 840 (+2) 842 (+2) 844 (+2) 846 (+2) 848 (+2) 850 (+2) 852 (+2) 854 (+2) 856 (+2) 858 (+2) 860 (+2) 862 (+2) 864 (+2) 866 (+2) 868 (+2) 871 (+3) 873 (+2) 811 (-62) 
```

Deux questions sur Unix StackExchange décrivant le même phénomène (trouvées plus loin):

Lekensteyn · Accepted Answer

Tout d'abord, l'affirmation selon laquelle "/proc/sys/kernel/random/entropy_avail Vous donne simplement le nombre de bits qui peuvent actuellement être lus à partir de /dev/random" est fausse.

Le champ entropy_avail Lit input_pool.entropy_count , le pool "de sortie" fait référence au pool utilisé pour urandom (pool non bloquant) et random (bloc de blocage).

Comme mentionné dans cette réponse , l'apparition de nouveaux processus consomme de l'entropie pour des choses comme ASLR. Le programme de surveillance engendre un nouveau processus pour chaque appel, peut-être que l'outil de surveillance fait de même (éventuellement via l'une des autres sources de surveillance qui doivent invoquer un programme externe pour obtenir le statut?).

Pour surveiller le bassin d'entropie sans le vider, vous pouvez essayer le programme entropie-observateur (voir la réponse liée).

En regardant attentivement les chiffres de entropy-watcher, Il semble que vous perdiez environ 64 bits d'entropie à intervalles. Sur la base de l'analyse de l'autre réponse, cela semble être le résultat du déplacement de l'entropie vers un "pool de sortie" pour éviter de le gaspiller. Ceci est observé sur Linux v4.6, les futures implémentations peuvent être différentes.

Sur la base du code source (drivers/char/random.c En v4.6), je peux voir que la lecture des pools de sortie (/dev/{u,}random Ou get_random_bytes()) appelle extract_entropy{,_user} Qui appelle xfer_secondary_pool et account. Le pool de blocage a la propriété limit set (r->limit == 1) Qui affecte les deux fonctions:

Pour account(), il ne renverra aucune donnée du pool de blocage si son entropie est trop faible. Pour le pool de sortie non bloquant, l'entropie restante sera consommée mais les données sont toujours renvoyées.
xfer_secondary_pool() garantit que suffisamment d'entropie est disponible dans le pool de sortie. Si le pool de sortie bloquant a une entropie insuffisante, il en prendra du pool d'entrée (si possible).
xfer_secondary_pool() pour le pool de sortie non bloquant se comporte spécialement selon le paramètre /proc/sys/kernel/random/urandom_min_reseed_secs. Si cette valeur est différente de zéro, l'entropie n'est prise dans le pool d'entrée que si au moins urandom_min_reseed_secs Secondes se sont écoulées depuis le dernier transfert. Par défaut, cette valeur est définie sur 60 secondes.

Le dernier point explique enfin pourquoi vous voyez un drain d'entropie dans le pool d'entrée toutes les 60 secondes. Si certains consommateurs demandent des octets aléatoires au pool de sortie non bloquant (numéros de séquence TCP, ASLR, /dev/urandom, getrandom(), ...), alors 128 bits seront consommés du pool d'entrée pour réamorcer le pool de sortie non bloquant.