J'ai un doute en lisant ta réponse, si le compteur ne fuyait pas je pourrait toujours faire un overflow. Il s'agit ici bien d'un overflow et non d'un underflow, il faut donc faire 232 appel de syscall, en soit ça il y a rien pour empêcher un programme en userspace d’appeler 232 fois le même syscall. Mais si tu avais pas de fuite du compteur, tu aurais 232 fois l'allocation de l'objet de keyring est niveau mémoire ça passerai difficilement (voir pas avec l'OOM killer qui rentrai en jeu). Parce que si j'ai bien compris, la dés-allocation est faite par le garbage collecteur qui croit qu'il n'y a plus d'objet référencé et donc clean la mémoire. Si j'avais 232 objets alloué le comportement serai le même, il me dés-allouerai le premier objet en croyant qu'il n'existe plus (compteur à 0). Mais avoir 232 allocation du même objet, en mémoire ça passera difficilement.
Y a quelque chose de faux dans mon raisonnement ?
La proposition 4 est intéressante et je me demande pourquoi cela n'est pas fait, sans doute parce cette struct xxx_ops doit être utilisé à beaucoup d'endroit avec des appels vers différentes functions. Si tu remplace le pointeur par un tableau statique tu fais grandir la taille de ta structure (un index par fonction référencé). J'ai bon ?
Les micro-noyaux c'est un autre débats, la méthode est anti-performante dans une architecture monolithique.
Mais pour ma culture personnelle, quel micro noyau existe (en dehors du monde universitaire) ? La plupart du temps les "micro-noyaux" ne sont en fait que des architecture hybride et niveau performance ça pas la panacée.
UDEREF j'ai pas encore creusé le sujet, c'est quoi le principe ? ça marche sur architecture ARM ou c'est uniquement du X86? Et pour quelles contraintes sur les performances ?
[^] # Re: Journal bookmark inutile.
Posté par Tangi Colin . En réponse au journal faille Linux 0 day du 19 janvier 2016. Évalué à 3.
J'ai un doute en lisant ta réponse, si le compteur ne fuyait pas je pourrait toujours faire un overflow. Il s'agit ici bien d'un overflow et non d'un underflow, il faut donc faire 232 appel de syscall, en soit ça il y a rien pour empêcher un programme en userspace d’appeler 232 fois le même syscall. Mais si tu avais pas de fuite du compteur, tu aurais 232 fois l'allocation de l'objet de keyring est niveau mémoire ça passerai difficilement (voir pas avec l'OOM killer qui rentrai en jeu). Parce que si j'ai bien compris, la dés-allocation est faite par le garbage collecteur qui croit qu'il n'y a plus d'objet référencé et donc clean la mémoire. Si j'avais 232 objets alloué le comportement serai le même, il me dés-allouerai le premier objet en croyant qu'il n'existe plus (compteur à 0). Mais avoir 232 allocation du même objet, en mémoire ça passera difficilement.
Y a quelque chose de faux dans mon raisonnement ?
La proposition 4 est intéressante et je me demande pourquoi cela n'est pas fait, sans doute parce cette struct xxx_ops doit être utilisé à beaucoup d'endroit avec des appels vers différentes functions. Si tu remplace le pointeur par un tableau statique tu fais grandir la taille de ta structure (un index par fonction référencé). J'ai bon ?
Les micro-noyaux c'est un autre débats, la méthode est anti-performante dans une architecture monolithique.
Mais pour ma culture personnelle, quel micro noyau existe (en dehors du monde universitaire) ? La plupart du temps les "micro-noyaux" ne sont en fait que des architecture hybride et niveau performance ça pas la panacée.
UDEREF j'ai pas encore creusé le sujet, c'est quoi le principe ? ça marche sur architecture ARM ou c'est uniquement du X86? Et pour quelles contraintes sur les performances ?
```