Je pense qu'il voulait dire que bien que le pool soit global, le niveau d'épuisement auquel réagir pourrait varier suivant le processus qui pourrait être utilisé pour réapprovisionner (le processus en question pourrait par exemple créer son fichier treshold propre, et l'enregistrer auprès du sous-système random). On pourrait notamment imaginer des sources d'entropie plus ou moins coûteuses/efficaces, qui seraient mises à contribution suivant l'urgence de la situation. Mais ça reste un peu artificiel.
Ceci dit, ça ne me semblerait pas délirant que scdrand respecte cette constante, qui est supposée représenter le seuil à partir duquel "quelqu'un" doit réapprovisionner le pool si possible, au lieu d'avoir son propre seuil.
Même si le seuil est relativement bas, le simple fait de réagir à une notification au lieu de vérifier périodiquement devrait permettre d'éviter encore plus les trous dans le niveau d'entropie.
Au passage, légèrement hors-sujet, je viens de tomber sur ce projet qui m'a l'air fort intéressant (mutualisation des sources d'entropie): http://www.vanheusden.com/entropybroker/
Justement les pertes de performance liées à la rareté de l'entropie en environnements virtualisés sont un de mes problèmes actuels, je suis content :)
Ça soulève pas mal de questions, bien sûr (notamment quant à la notion de distribution de confiance), mais c'est sympa de voir qu'il y a des tentatives de solution.
[^] # Re: pilote noyau
Posté par Yann Hodique (site web personnel) . En réponse à la dépêche scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce. Évalué à 4. Dernière modification le 19 août 2014 à 06:22.
Je pense qu'il voulait dire que bien que le pool soit global, le niveau d'épuisement auquel réagir pourrait varier suivant le processus qui pourrait être utilisé pour réapprovisionner (le processus en question pourrait par exemple créer son fichier treshold propre, et l'enregistrer auprès du sous-système random). On pourrait notamment imaginer des sources d'entropie plus ou moins coûteuses/efficaces, qui seraient mises à contribution suivant l'urgence de la situation. Mais ça reste un peu artificiel.
Ceci dit, ça ne me semblerait pas délirant que scdrand respecte cette constante, qui est supposée représenter le seuil à partir duquel "quelqu'un" doit réapprovisionner le pool si possible, au lieu d'avoir son propre seuil.
Même si le seuil est relativement bas, le simple fait de réagir à une notification au lieu de vérifier périodiquement devrait permettre d'éviter encore plus les trous dans le niveau d'entropie.
Au passage, légèrement hors-sujet, je viens de tomber sur ce projet qui m'a l'air fort intéressant (mutualisation des sources d'entropie): http://www.vanheusden.com/entropybroker/
Justement les pertes de performance liées à la rareté de l'entropie en environnements virtualisés sont un de mes problèmes actuels, je suis content :)
Ça soulève pas mal de questions, bien sûr (notamment quant à la notion de distribution de confiance), mais c'est sympa de voir qu'il y a des tentatives de solution.