Le Thu, 13 Jan 2005 17:12:19 +0000, Nicolas George s'exprimait :
Olivier Beyssac , dans le message , a écrit :
Tu oublies peut-être un détail, maintenant que j'y pense : « It is only exploitable on multiprocessor machines (that also includes systems with hyperthreading). »
C'est tout de suite beaucoup plus courant que le SMP « pur ».
Il ne suffit pas que le processeur le supporte, il faut que le noyau ait été configuré pour l'utiliser.
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au boot était le SMP, même si grub proposait aussi le noyau normal.
-- The best oxymoron : Microsoft Works ®
Le Thu, 13 Jan 2005 17:12:19 +0000, Nicolas George s'exprimait :
Olivier Beyssac , dans le message <86acrdb6hh.fsf@r14.redhate.org>, a
écrit :
Tu oublies peut-être un détail, maintenant que j'y pense :
« It is only exploitable on multiprocessor machines (that also includes
systems with hyperthreading). »
C'est tout de suite beaucoup plus courant que le SMP « pur ».
Il ne suffit pas que le processeur le supporte, il faut que le noyau ait été
configuré pour l'utiliser.
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au
boot était le SMP, même si grub proposait aussi le noyau normal.
Le Thu, 13 Jan 2005 17:12:19 +0000, Nicolas George s'exprimait :
Olivier Beyssac , dans le message , a écrit :
Tu oublies peut-être un détail, maintenant que j'y pense : « It is only exploitable on multiprocessor machines (that also includes systems with hyperthreading). »
C'est tout de suite beaucoup plus courant que le SMP « pur ».
Il ne suffit pas que le processeur le supporte, il faut que le noyau ait été configuré pour l'utiliser.
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au boot était le SMP, même si grub proposait aussi le noyau normal.
-- The best oxymoron : Microsoft Works ®
Nicolas George
Shmurtz , dans le message , a écrit :
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au boot était le SMP, même si grub proposait aussi le noyau normal.
Quelle drôle d'idée de leur part. Bon, venant de Fedora, je ne m'étonne de rien. Il me semble que sur certaines machines, il faut en plus activer l'hyperthreading dans le BIOS.
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à rendre possibles les conditions du trou.
Shmurtz , dans le message <pan.2005.01.14.18.28.35.708303@pundit-r.org>,
a écrit :
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au
boot était le SMP, même si grub proposait aussi le noyau normal.
Quelle drôle d'idée de leur part. Bon, venant de Fedora, je ne m'étonne de
rien. Il me semble que sur certaines machines, il faut en plus activer
l'hyperthreading dans le BIOS.
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très
dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à
rendre possibles les conditions du trou.
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au boot était le SMP, même si grub proposait aussi le noyau normal.
Quelle drôle d'idée de leur part. Bon, venant de Fedora, je ne m'étonne de rien. Il me semble que sur certaines machines, il faut en plus activer l'hyperthreading dans le BIOS.
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à rendre possibles les conditions du trou.
Olivier Beyssac
Nicolas George <nicolas$ writes:
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à rendre possibles les conditions du trou.
Vu que d'une part SMP et HT semblent (sauf erreur) la même chose vus depuis le noyau et que d'autre part le texte lui-même de l'advisory précise que les noyaux supportant le HT sont touchés, j'ai peu de doutes.
-- Olivier Beyssac -
Nicolas George <nicolas$george@salle-s.org> writes:
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très
dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à
rendre possibles les conditions du trou.
Vu que d'une part SMP et HT semblent (sauf erreur) la même chose vus
depuis le noyau et que d'autre part le texte lui-même de l'advisory
précise que les noyaux supportant le HT sont touchés, j'ai peu de
doutes.
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à rendre possibles les conditions du trou.
Vu que d'une part SMP et HT semblent (sauf erreur) la même chose vus depuis le noyau et que d'autre part le texte lui-même de l'advisory précise que les noyaux supportant le HT sont touchés, j'ai peu de doutes.
-- Olivier Beyssac -
Shmurtz
Le Sat, 15 Jan 2005 11:14:04 +0000, Nicolas George s'exprimait :
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au boot était le SMP, même si grub proposait aussi le noyau normal.
Quelle drôle d'idée de leur part. Bon, venant de Fedora, je ne m'étonne de rien. Il me semble que sur certaines machines, il faut en plus activer l'hyperthreading dans le BIOS.
D'après des commentaires dans diverses listes de diffusion, on pouvait gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à rendre possibles les conditions du trou.
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si ce n'est qu'un des deux processeurs est virtuel.
-- The best oxymoron : Microsoft Works ®
Le Sat, 15 Jan 2005 11:14:04 +0000, Nicolas George s'exprimait :
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au
boot était le SMP, même si grub proposait aussi le noyau normal.
Quelle drôle d'idée de leur part. Bon, venant de Fedora, je ne m'étonne de
rien. Il me semble que sur certaines machines, il faut en plus activer
l'hyperthreading dans le BIOS.
D'après des commentaires dans diverses listes de diffusion, on pouvait
gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple
était une perte de perfs catastrophique lors de l'utilisation de Jack
(the ripper) qui est pourtant fait pour tirer parti du SMP.
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très
dégénérée de parallélisme, et il n'est pas du tout clair qu'il
suffise à rendre possibles les conditions du trou.
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si
ce n'est qu'un des deux processeurs est virtuel.
Le Sat, 15 Jan 2005 11:14:04 +0000, Nicolas George s'exprimait :
J'avais installé une Fedora pour un P4 2.8 GHz et le noyau par défaut au boot était le SMP, même si grub proposait aussi le noyau normal.
Quelle drôle d'idée de leur part. Bon, venant de Fedora, je ne m'étonne de rien. Il me semble que sur certaines machines, il faut en plus activer l'hyperthreading dans le BIOS.
D'après des commentaires dans diverses listes de diffusion, on pouvait gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Enfin, je viens de penser à ceci : l'HT est une forme vraiment très dégénérée de parallélisme, et il n'est pas du tout clair qu'il suffise à rendre possibles les conditions du trou.
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si ce n'est qu'un des deux processeurs est virtuel.
-- The best oxymoron : Microsoft Works ®
Manuel Leclerc
Irvin Probst writes :
De plus on voit à la fin "A proof of concept code won't be disclosed now." donc notre ami script kiddie va devoir ronger son frein le temps que ça soit publié.
C'est vrai, il a de toute façon largement de quoi s'occuper avec l'exploit publié vendredi soir :)
Une PoC datant de Jeudi, jour où j'ai posté http://www.k-otik.com/exploits/20050113.stackgrow.c.php
A noter que la CAN-2005-0001 est maintenant consultable http://cve.mitre.org/cgi-bin/cvename.cgi?nameÊN-2005-0001 Je n'arrivais pas à la voir Jeudi. On y lit une date d'origine au 3 janvier (?), et une description ** RESERVED **
<Troll En Charte> Ne serait-ce pas une confirmation que c'est un peu le bordel la sécurité du Kernel en ce moment et que des gens se mettent à publier failles, voir PoC, un peu "tôt" histoire de faire bouger les choses ? </Troll En Charte>
-- Il s'agit d'un dysfonctionnement que je signale bénévolement sur mon temps libre. --Dr. Justin Pochard
Irvin Probst writes :
De plus on voit à la fin "A proof of concept code
won't be disclosed now." donc notre ami script
kiddie va devoir ronger son frein le temps que ça
soit publié.
C'est vrai, il a de toute façon largement de quoi
s'occuper avec l'exploit publié vendredi soir :)
Une PoC datant de Jeudi, jour où j'ai posté
http://www.k-otik.com/exploits/20050113.stackgrow.c.php
A noter que la CAN-2005-0001 est maintenant consultable
http://cve.mitre.org/cgi-bin/cvename.cgi?nameÊN-2005-0001
Je n'arrivais pas à la voir Jeudi. On y lit une date
d'origine au 3 janvier (?), et une description ** RESERVED **
<Troll En Charte>
Ne serait-ce pas une confirmation que c'est un peu le bordel
la sécurité du Kernel en ce moment et que des gens se mettent
à publier failles, voir PoC, un peu "tôt" histoire de faire
bouger les choses ?
</Troll En Charte>
--
Il s'agit d'un dysfonctionnement que je signale bénévolement sur mon
temps libre.
--Dr. Justin Pochard
De plus on voit à la fin "A proof of concept code won't be disclosed now." donc notre ami script kiddie va devoir ronger son frein le temps que ça soit publié.
C'est vrai, il a de toute façon largement de quoi s'occuper avec l'exploit publié vendredi soir :)
Une PoC datant de Jeudi, jour où j'ai posté http://www.k-otik.com/exploits/20050113.stackgrow.c.php
A noter que la CAN-2005-0001 est maintenant consultable http://cve.mitre.org/cgi-bin/cvename.cgi?nameÊN-2005-0001 Je n'arrivais pas à la voir Jeudi. On y lit une date d'origine au 3 janvier (?), et une description ** RESERVED **
<Troll En Charte> Ne serait-ce pas une confirmation que c'est un peu le bordel la sécurité du Kernel en ce moment et que des gens se mettent à publier failles, voir PoC, un peu "tôt" histoire de faire bouger les choses ? </Troll En Charte>
-- Il s'agit d'un dysfonctionnement que je signale bénévolement sur mon temps libre. --Dr. Justin Pochard
Nicolas George
Shmurtz , dans le message , a écrit :
D'après des commentaires dans diverses listes de diffusion, on pouvait gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Un ami à moi avait eu de nettes baisses de performances sur je ne sais plus quoi.
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si ce n'est qu'un des deux processeurs est virtuel.
Non, ce n'est pas si simple. L'HT propose bien deux unités de calcul, mais seulement une MMU. Donc un processeur HT ne peut pas exécuter simultanément deux processus quelconques, uniquement deux threads d'un même processus. C'est vraiment très différent d'un vrai SMP, mais ça demande un support similaire du verrouillage des structures noyau.
Shmurtz , dans le message <pan.2005.01.15.14.29.00.988325@pundit-r.org>,
a écrit :
D'après des commentaires dans diverses listes de diffusion, on pouvait
gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple
était une perte de perfs catastrophique lors de l'utilisation de Jack
(the ripper) qui est pourtant fait pour tirer parti du SMP.
Un ami à moi avait eu de nettes baisses de performances sur je ne sais plus
quoi.
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si
ce n'est qu'un des deux processeurs est virtuel.
Non, ce n'est pas si simple. L'HT propose bien deux unités de calcul, mais
seulement une MMU. Donc un processeur HT ne peut pas exécuter simultanément
deux processus quelconques, uniquement deux threads d'un même processus.
C'est vraiment très différent d'un vrai SMP, mais ça demande un support
similaire du verrouillage des structures noyau.
D'après des commentaires dans diverses listes de diffusion, on pouvait gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Un ami à moi avait eu de nettes baisses de performances sur je ne sais plus quoi.
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si ce n'est qu'un des deux processeurs est virtuel.
Non, ce n'est pas si simple. L'HT propose bien deux unités de calcul, mais seulement une MMU. Donc un processeur HT ne peut pas exécuter simultanément deux processus quelconques, uniquement deux threads d'un même processus. C'est vraiment très différent d'un vrai SMP, mais ça demande un support similaire du verrouillage des structures noyau.
Thierry Boudet
On 2005-01-15, Shmurtz wrote:
était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Jack, le processeur audio, ou John le craqueur de passwd ?
-- _/°< coin
On 2005-01-15, Shmurtz <shmurtz@pundit-r.org> wrote:
était une perte de perfs catastrophique lors de l'utilisation de Jack
(the ripper) qui est pourtant fait pour tirer parti du SMP.
Jack, le processeur audio, ou John le craqueur de passwd ?
était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Jack, le processeur audio, ou John le craqueur de passwd ?
-- _/°< coin
Shmurtz
Le Sun, 16 Jan 2005 16:08:48 +0000, Nicolas George s'exprimait :
Shmurtz , dans le message , a écrit :
D'après des commentaires dans diverses listes de diffusion, on pouvait gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Un ami à moi avait eu de nettes baisses de performances sur je ne sais plus quoi.
Voir un petit test qui ne veut pas dire grand chose, ici :
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si ce n'est qu'un des deux processeurs est virtuel.
Non, ce n'est pas si simple. L'HT propose bien deux unités de calcul, mais seulement une MMU. Donc un processeur HT ne peut pas exécuter simultanément deux processus quelconques, uniquement deux threads d'un même processus.
C'est donc pour cela que certaines personnes parlaient d'SMT.
-- The best oxymoron : Microsoft Works ®
Le Sun, 16 Jan 2005 16:08:48 +0000, Nicolas George s'exprimait :
Shmurtz , dans le message <pan.2005.01.15.14.29.00.988325@pundit-r.org>,
a écrit :
D'après des commentaires dans diverses listes de diffusion, on pouvait
gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple
était une perte de perfs catastrophique lors de l'utilisation de Jack
(the ripper) qui est pourtant fait pour tirer parti du SMP.
Un ami à moi avait eu de nettes baisses de performances sur je ne sais plus
quoi.
Voir un petit test qui ne veut pas dire grand chose, ici :
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si
ce n'est qu'un des deux processeurs est virtuel.
Non, ce n'est pas si simple. L'HT propose bien deux unités de calcul, mais
seulement une MMU. Donc un processeur HT ne peut pas exécuter simultanément
deux processus quelconques, uniquement deux threads d'un même processus.
C'est donc pour cela que certaines personnes parlaient d'SMT.
Le Sun, 16 Jan 2005 16:08:48 +0000, Nicolas George s'exprimait :
Shmurtz , dans le message , a écrit :
D'après des commentaires dans diverses listes de diffusion, on pouvait gagner 10 à 15 % de temps sur une compilation de prog. Le contre exemple était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Un ami à moi avait eu de nettes baisses de performances sur je ne sais plus quoi.
Voir un petit test qui ne veut pas dire grand chose, ici :
Le noyau voit deux cpu, je pense qu'il fonctionne de la même manière, si ce n'est qu'un des deux processeurs est virtuel.
Non, ce n'est pas si simple. L'HT propose bien deux unités de calcul, mais seulement une MMU. Donc un processeur HT ne peut pas exécuter simultanément deux processus quelconques, uniquement deux threads d'un même processus.
C'est donc pour cela que certaines personnes parlaient d'SMT.
-- The best oxymoron : Microsoft Works ®
Shmurtz
Le Mon, 17 Jan 2005 13:35:09 +0000, Thierry Boudet s'exprimait :
On 2005-01-15, Shmurtz wrote:
était une perte de perfs catastrophique lors de l'utilisation de Jack (the ripper) qui est pourtant fait pour tirer parti du SMP.
Jack, le processeur audio, ou John le craqueur de passwd ?
Le front end pour ripper/encoder :
http://www.home.unix-ag.org/arne/jack/
-- The best oxymoron : Microsoft Works ®
Le Mon, 17 Jan 2005 13:35:09 +0000, Thierry Boudet s'exprimait :
On 2005-01-15, Shmurtz <shmurtz@pundit-r.org> wrote:
était une perte de perfs catastrophique lors de l'utilisation de Jack
(the ripper) qui est pourtant fait pour tirer parti du SMP.
Jack, le processeur audio, ou John le craqueur de passwd ?
