- un script rsync avec cron : fonctionne mais ça à l'air lent
La première chose à faire lorsqu'on cherche à optimiser, c'est de mesurer. Avoir l'air lent, c'est très vague. Commence par utiliser time pour voir le temps total, et le temps passé en user et système, et deduis-en le débit. Vérifie si le goulot n'est pas le réseau, auquel cas une compression des données pourrait être intéressante (supportée par rsync mais pas ftp).
Avant d'aller plus loin, mesure !
Euh non, NULL == 0 ou NULL == (void*)0, mais dans tous les cas NULL == 0, sinon dans le K&R, tous les cas de test de type if (!ptr) { ... } seraient à jeter.
Dans un contexte de pointeur, un 0 est converti en pointeur NULL. Donc if (!ptr), qui est en fait if (ptr != 0) est converti en if (ptr != NULL).
Par contre, NULL n'est pas forcément défini comme ayant tous les bits à 0. Dans un programme, il est représenté par 0 ou (void *)0 mais derrière, le code généré ne se traduit pas forcément par 0x00000000 :
Some Honeywell-Bull mainframes use the bit pattern 06000 for (internal) null pointers. The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, and offset. Most users (in ring 11) have null pointers of 0xB00000000000. It was common on old CDC ones- complement machines to use an all-one-bits word as a special flag for all kinds of data, including invalid addresses.
Si un processus en espace utilisateur accède à l'adresse 0, il accède à l'adresse virtuelle 0 de l'ensemble du système ?
Il n'y a pas "d'adresse virtuelle 0 de l'ensemble du système". Il y a une adresses virtuelle 0 par process, par table des pages. L'adresse virtuelle 0 du process X ne correspond pas à l'adresse virtuelle 0 du process Y (pour peu qu'elles soient mappées).
Dans un cas comme dans l'autre je ne vois pas pourquoi l'adresse 0 n'est pas en read only (et exécutable si c'est une adresse 0 par processus).
Pour les raisons expliquées plus haut (vm86, doesmu), l'adresse 0 doit pouvoir être mappée et exécutable dans certains cas.
En fait, on s'en fout que ce soit l'adresse 0. Dis-toi que c'est comme n'importe quel déréférencement de pointeur invalide. Si l'adresse en question appartient à une page est mappée et exécutable, alors tu as le même risque d'exploit. La seule différence, c'est qu'un pointeur null est bien plus courant et donc facile à exploiter que 0xc76b8d00.
Je croyais que processus avait son propre espace d'adressage duquel il ne peut pas sortir
En mode utilisateur, oui. Il y a une table des pages par process, avec le kernel mappé dans chaque table à partir d'une adresse fixe (par défaut 0xC0000000).
Lorsque le process passe en mode noyau, il a accès à toutes les adresses du système (adresses virtuelles, logiques ou physiques).
en fait je pensais que l'adresse 0 était l'adresse 0 du programme et pas du système. (Je sais pas si c'est très clair) Hors au début de l'espace d'adressage il y à la section de code qui je pense devrais être en lecture seule, non ?
Lorsque tu mmap, en mode utilisateur, du code exécutable à l'adresse zero (_pour le process_), il est marqué, dans la table des pages _du process_ , comme exécutable : donc, lorsque plus tard, le process, qui tourne cette fois en mode noyau, déréférence l'adresse 0, il peut exécuter le code en question (car l'entrée correspondante dans sa table des pages est marquée comme exécutable, pas d'exception levée par le processeur), le code est tout simplement executé, _en mode noyau_. Et là, c'est le drame.
Parce que certaines applications ont besoin de pouvoir ce mapper à l'adresse 0, par exemple quand on bosse avec des émulateurs ou machine virtuelles (dosemu, wine, et d'autres). Mais le mieux c'est d'utiliser les capabilities juste pour l'application en question.
En fait si, ça existe déjà.
Des analyseurs statiques comme coverity avaient déjà détecté de tels bugs (déréférencement pointeur NULL), mais pas tous.
Ensuite, dans le cas évoqué, l'auteur du journal a oublié de préciser une chose. L'exploit utilisait un comportement de gcc très particulier : en analysant le flot du code, gcc voyait qu'on effectuait un check sur la nullité du pointeur _après_ l'avoir déréférencé (mais ce déréférencement n'était pas exploitable), et du coup supprimait (optimisait) la vérification du pointeur null, se disant qu'il ne pouvait pas l'être parce que s'il était null, on n'aurait pas pu le déréférencer (ou on aurait crashé). Du coup, l'éxécution se poursuivait alors que le code n'aurait _jamais_ dû être exécuté.
Brad a fait tout un foin de cette faille, mais ce n'est en rien une "nouveau type de faille". C'est juste un déréférencement du pointeur non initialisé, point barre.
Je connaissais un développeur qui travaillait sur le port vers L4, qui a laissé tombé lorsque la décision a été prise de basculer vers Coyotos. Il disait que les développeurs principaux ne considéraient pas le Hurd comme un projet destiné à donner un OS utilisable, mais plutôt comme un projet de recherche.
A vrai dire, je suis plus intéressé par Minix depuis la version 3. A ce sujet, Tanenbaum va faire une présentation de Minix au FOSDEM qui se tiendra la semaine prochaine à Bruxelles, avis aux intéressés.
Les logiciels de capture sont très utiles, mais ont deux gros inconvénients qui en font un cauchemar pour la sécurité :
- ils tournent en root (il faut voir si on peut éviter cela avec des capabilities)
- ils parsent des données potentiellement très dangereuse, puisque circulant sur le réseau, ou internet
Je ne sais pas comment ils font, mais je pense que pour ce type d'application, des tests automatiques pourraient être utiles.
On fait tourner un ethereal, et on balance des trames formattées au hasard, ou selon un pattern. Je pense que ça permettrait déjà de détecter pas mal de problème, couplé à valgrind.
Ethereal est connu pour être une passoire, notamment au niveau des dissectors...
Aux dernières nouvelle, la séparation des privilèges n'est pas implémentée.
SIGSTOP c'est génial, sauf que s'il arrive pendant un appel système, on risque de se prendre un EINTR, qui n'est pas toujours traité dans les applications. Mieux vaut ne pas se prendre un EINTR lors d'un connect par exemple... Le mécanisme de suspension est bien mieux géré par l'application que par le noyau.
Si l'implémentation utilise des threads en user-level (par exemple OpenBSD), alors les threads ne pourront pas tourner en parallèle sur différents processeurs.
Non.
Ce qui est mal, c'est d'écrire un journal qui prétend comparer deux systèmes d'exploitation en une vingtaine de lignes.
Ce qui est mal, c'est de prétendre comparer deux systèmes que l'on ne maîtrise visiblement pas.
Ce qui est mal, c'est de poster Yet Another Useless Journal.
Certains vont me répondre que je ne suis pas obligé de lire ce journal, que je peux passer mon chemin. Certes, mais je trouve qu'il est de plus en plus difficile de trouver des contenus intéressants sur le net, parce qu'entre les blogs de personnes qui n'ont rien à dire et ne connaissent rien mais se sentent obligés de raconter leur vie, les articles techniques écrits par des gens dont la formation se résume à "la micro-informatique en 15 jours", et les journaux écrits par des Kevin élèves de troisième, cela en fait un paquet de conneries à filtrer. Le rapport signal/bruit diminue fortement sur le net, et je trouve dommage que cela affecte un site comme DLFP, qui a des contributeurs d'un tout autre niveau.
sysrq dump dans les logs noyaux, que tu peux voir avec un "dmesg" ou dans /var/log/messages.
Pour le strace, il faut le faire sur les process qui bloquent, pas sur les process noyau.
On dirait que tu es tombé sur une régression...
En vrac :
- un "strace -T" sur les process en question serait utile pour voir où ils sont bloqués (mais c'est très probablement sur un write ;-)
- la sortie d'un "cat /proc/meminfo" pourrait être intéressante
- est-ce que des "sync" en background améliorent les choses ?
- rien de spécial dans "var/log/messages" ?
- que donne un "echo t > /proc/sysrq-trigger" lors d'un blocage ?
Ce serait pas mal de reporter le problème sur la mailing liste du noyau...
Posté par neologix .
En réponse au sondage MacOS X.
Évalué à 2.
J'ai déjà pris l'habitude de le laisser en veille la nuit (je sais c'est pas écolo, mais ça permet de laisser 50 onglets ouverts dans Safari^WFirefox).
S'il n'y a que ça...
Tu peux sauvegarder tous les onglets courants dans un dossier temporaire ("bookmark all tabs"), et les restaurer au redémarrage suivant ("open all in tabs").
L'autre avantage c'est que ça évite d'avoir firefox qui consomme 512Mo de mémoire au bout de 3 jours avec deux onglets...
Cela vient peut-être de moi, mais j'ai l'impression que depuis quelques années, de plus en plus de moyens sont investis dans les effets spéciaux, et de moins en moins dans l'écriture des scénarios et le choix des acteurs.
Je suis peut-être un vieux con, mais je ne vois pas ce qu'apporte un film avec des humanoïdes bleus, même s'il est en 3D/numérique/full HD.
Enfin, je ne comprends pas non plus Facebook/Twiter/Iphone et ces réseaux asociaux, je dois être dépassé...
Est il vraiment possible que le kernel m'impose une latence de l'ordre de la seconde ?!!
Oui.
Le noyau Linux vanilla n'est pas temps réel.
Tu pourrais essayer avec d'autres ordonnanceurs d'E/S.
Je suppose que RHEL utilise CFQ par défaut, tu peux essayer avec deadline.
Essaie de relancer ton rsync avec la variable d'environnement MALLOC_CHECK_=1
Si tu as le temps, tu peux recompiler rsync avec les informations de debug, et le lancer sous Valgrind.
Sinon, pour réduir le temps de démarrage des applications après une grosse copie par exemple, il y a le patch swap-prefetch de Con Kolivas : http://ck.wikia.com/wiki/SwapPrefetch
Gestion des threads noyaux :
Le noyau gère désormais les processus légers. Le passage à l'utilisation des processus légers apporte une réduction de la consommation des ressources bas niveau du système.
Jusqu'à présent, il n'existait pas de threads noyau sous FreeBSD ? Les implémentations existantes utilisaient des threads en espace utilisateur ?
# mesure !
Posté par neologix . En réponse au message cherche logiciel de backup ftp, rsync ou autre. Évalué à 10.
La première chose à faire lorsqu'on cherche à optimiser, c'est de mesurer. Avoir l'air lent, c'est très vague. Commence par utiliser time pour voir le temps total, et le temps passé en user et système, et deduis-en le débit. Vérifie si le goulot n'est pas le réseau, auquel cas une compression des données pourrait être intéressante (supportée par rsync mais pas ftp).
Avant d'aller plus loin, mesure !
[^] # Re: Et pour ceux qui n'y connaissent rien...
Posté par neologix . En réponse au journal Un autre type de faille locale. Évalué à 9.
Dans un contexte de pointeur, un 0 est converti en pointeur NULL. Donc if (!ptr), qui est en fait if (ptr != 0) est converti en if (ptr != NULL).
Par contre, NULL n'est pas forcément défini comme ayant tous les bits à 0. Dans un programme, il est représenté par 0 ou (void *)0 mais derrière, le code généré ne se traduit pas forcément par 0x00000000 :
Some Honeywell-Bull mainframes use the bit pattern 06000 for (internal) null pointers. The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, and offset. Most users (in ring 11) have null pointers of 0xB00000000000. It was common on old CDC ones- complement machines to use an all-one-bits word as a special flag for all kinds of data, including invalid addresses.
Read more: http://www.faqs.org/faqs/C-faq/faq/#ixzz0g5YOWMAY
Pour plus d'informations, la bible :
http://www.faqs.org/faqs/C-faq/faq/
section 5
[^] # Re: Et pour ceux qui n'y connaissent rien...
Posté par neologix . En réponse au journal Un autre type de faille locale. Évalué à 3.
Il n'y a pas "d'adresse virtuelle 0 de l'ensemble du système". Il y a une adresses virtuelle 0 par process, par table des pages. L'adresse virtuelle 0 du process X ne correspond pas à l'adresse virtuelle 0 du process Y (pour peu qu'elles soient mappées).
Dans un cas comme dans l'autre je ne vois pas pourquoi l'adresse 0 n'est pas en read only (et exécutable si c'est une adresse 0 par processus).
Pour les raisons expliquées plus haut (vm86, doesmu), l'adresse 0 doit pouvoir être mappée et exécutable dans certains cas.
En fait, on s'en fout que ce soit l'adresse 0. Dis-toi que c'est comme n'importe quel déréférencement de pointeur invalide. Si l'adresse en question appartient à une page est mappée et exécutable, alors tu as le même risque d'exploit. La seule différence, c'est qu'un pointeur null est bien plus courant et donc facile à exploiter que 0xc76b8d00.
[^] # Re: Et pour ceux qui n'y connaissent rien...
Posté par neologix . En réponse au journal Un autre type de faille locale. Évalué à 2.
En mode utilisateur, oui. Il y a une table des pages par process, avec le kernel mappé dans chaque table à partir d'une adresse fixe (par défaut 0xC0000000).
Lorsque le process passe en mode noyau, il a accès à toutes les adresses du système (adresses virtuelles, logiques ou physiques).
en fait je pensais que l'adresse 0 était l'adresse 0 du programme et pas du système. (Je sais pas si c'est très clair) Hors au début de l'espace d'adressage il y à la section de code qui je pense devrais être en lecture seule, non ?
Lorsque tu mmap, en mode utilisateur, du code exécutable à l'adresse zero (_pour le process_), il est marqué, dans la table des pages _du process_ , comme exécutable : donc, lorsque plus tard, le process, qui tourne cette fois en mode noyau, déréférence l'adresse 0, il peut exécuter le code en question (car l'entrée correspondante dans sa table des pages est marquée comme exécutable, pas d'exception levée par le processeur), le code est tout simplement executé, _en mode noyau_. Et là, c'est le drame.
[^] # Re: Et pour ceux qui n'y connaissent rien...
Posté par neologix . En réponse au journal Un autre type de faille locale. Évalué à 4.
[^] # Re: Analyseur statique...
Posté par neologix . En réponse au journal Un autre type de faille locale. Évalué à 8.
Des analyseurs statiques comme coverity avaient déjà détecté de tels bugs (déréférencement pointeur NULL), mais pas tous.
Ensuite, dans le cas évoqué, l'auteur du journal a oublié de préciser une chose. L'exploit utilisait un comportement de gcc très particulier : en analysant le flot du code, gcc voyait qu'on effectuait un check sur la nullité du pointeur _après_ l'avoir déréférencé (mais ce déréférencement n'était pas exploitable), et du coup supprimait (optimisait) la vérification du pointeur null, se disant qu'il ne pouvait pas l'être parce que s'il était null, on n'aurait pas pu le déréférencer (ou on aurait crashé). Du coup, l'éxécution se poursuivait alors que le code n'aurait _jamais_ dû être exécuté.
Brad a fait tout un foin de cette faille, mais ce n'est en rien une "nouveau type de faille". C'est juste un déréférencement du pointeur non initialisé, point barre.
# pas grand-chose...
Posté par neologix . En réponse au journal Arch Hurd: Nouveau projet autour de GNU/Hurd. Évalué à 10.
A vrai dire, je suis plus intéressé par Minix depuis la version 3. A ce sujet, Tanenbaum va faire une présentation de Minix au FOSDEM qui se tiendra la semaine prochaine à Bruxelles, avis aux intéressés.
[^] # Re: sécurité...
Posté par neologix . En réponse au journal WireShark la capture réseau. Évalué à 2.
- ils tournent en root (il faut voir si on peut éviter cela avec des capabilities)
- ils parsent des données potentiellement très dangereuse, puisque circulant sur le réseau, ou internet
Je ne sais pas comment ils font, mais je pense que pour ce type d'application, des tests automatiques pourraient être utiles.
On fait tourner un ethereal, et on balance des trames formattées au hasard, ou selon un pattern. Je pense que ça permettrait déjà de détecter pas mal de problème, couplé à valgrind.
[^] # Re: sécurité...
Posté par neologix . En réponse au journal WireShark la capture réseau. Évalué à 2.
Aux dernières nouvelle, la séparation des privilèges n'est pas implémentée.
[^] # Re: $ cp
Posté par neologix . En réponse à la dépêche Sortie de la version finale d'ultracopier. Évalué à 0.
# user-level vs kernel-level
Posté par neologix . En réponse au message pthread : multi-processeur/multi-cœur ?. Évalué à -1.
# SNMP
Posté par neologix . En réponse au message Detection du nombre de processeurs (cores). Évalué à 1.
$ snmpwalk -v 1 -c public \<host\> hrProcessorTable | wc -l[^] # Re: Ça commence mal...
Posté par neologix . En réponse au journal Windows 7. Évalué à 0.
Ce qui est mal, c'est d'écrire un journal qui prétend comparer deux systèmes d'exploitation en une vingtaine de lignes.
Ce qui est mal, c'est de prétendre comparer deux systèmes que l'on ne maîtrise visiblement pas.
Ce qui est mal, c'est de poster Yet Another Useless Journal.
Certains vont me répondre que je ne suis pas obligé de lire ce journal, que je peux passer mon chemin. Certes, mais je trouve qu'il est de plus en plus difficile de trouver des contenus intéressants sur le net, parce qu'entre les blogs de personnes qui n'ont rien à dire et ne connaissent rien mais se sentent obligés de raconter leur vie, les articles techniques écrits par des gens dont la formation se résume à "la micro-informatique en 15 jours", et les journaux écrits par des Kevin élèves de troisième, cela en fait un paquet de conneries à filtrer. Le rapport signal/bruit diminue fortement sur le net, et je trouve dommage que cela affecte un site comme DLFP, qui a des contributeurs d'un tout autre niveau.
[^] # Re: Si la piste du processus noyau est la bonne ...
Posté par neologix . En réponse au message Flush disque qui fait "freezer" la machine. Évalué à 1.
Pour le strace, il faut le faire sur les process qui bloquent, pas sur les process noyau.
[^] # Re: Si la piste du processus noyau est la bonne ...
Posté par neologix . En réponse au message Flush disque qui fait "freezer" la machine. Évalué à 2.
En vrac :
- un "strace -T" sur les process en question serait utile pour voir où ils sont bloqués (mais c'est très probablement sur un write ;-)
- la sortie d'un "cat /proc/meminfo" pourrait être intéressante
- est-ce que des "sync" en background améliorent les choses ?
- rien de spécial dans "var/log/messages" ?
- que donne un "echo t > /proc/sysrq-trigger" lors d'un blocage ?
Ce serait pas mal de reporter le problème sur la mailing liste du noyau...
[^] # Re: est un bon système, mais...
Posté par neologix . En réponse au sondage MacOS X. Évalué à 2.
S'il n'y a que ça...
Tu peux sauvegarder tous les onglets courants dans un dossier temporaire ("bookmark all tabs"), et les restaurer au redémarrage suivant ("open all in tabs").
L'autre avantage c'est que ça évite d'avoir firefox qui consomme 512Mo de mémoire au bout de 3 jours avec deux onglets...
# une tendance générale
Posté par neologix . En réponse à la dépêche Mieux vaut Avatar qu'un navet. Évalué à 10.
Je suis peut-être un vieux con, mais je ne vois pas ce qu'apporte un film avec des humanoïdes bleus, même s'il est en 3D/numérique/full HD.
Enfin, je ne comprends pas non plus Facebook/Twiter/Iphone et ces réseaux asociaux, je dois être dépassé...
[^] # Re: Je ne sais pas si ils vont réussir à déployer un réseau
Posté par neologix . En réponse au journal And then they were four .... Évalué à 2.
[^] # Re: Faut faire du Realtime!
Posté par neologix . En réponse au message Délai pendant l'exécution d'un fwrite. Évalué à 2.
Oui.
Le noyau Linux vanilla n'est pas temps réel.
Tu pourrais essayer avec d'autres ordonnanceurs d'E/S.
Je suppose que RHEL utilise CFQ par défaut, tu peux essayer avec deadline.
# MALLOC_CHECK_
Posté par neologix . En réponse au message Rsync en panne ? avec l'option A ?. Évalué à 2.
Si tu as le temps, tu peux recompiler rsync avec les informations de debug, et le lancer sous Valgrind.
[^] # Re: Les grosses copies de fichiers sous Linux
Posté par neologix . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 1.
echo 0 > /proc/sys/vm/swappinessSinon, pour réduir le temps de démarrage des applications après une grosse copie par exemple, il y a le patch swap-prefetch de Con Kolivas : http://ck.wikia.com/wiki/SwapPrefetch
[^] # Re: Exemple d'utilisation
Posté par neologix . En réponse au journal executions de commandes shell en parallele: par. Évalué à 2.
# threads sous FreeBSD
Posté par neologix . En réponse à la dépêche Sortie de FreeBSD 8.0-RELEASE. Évalué à 2.
Le noyau gère désormais les processus légers. Le passage à l'utilisation des processus légers apporte une réduction de la consommation des ressources bas niveau du système.
Jusqu'à présent, il n'existait pas de threads noyau sous FreeBSD ? Les implémentations existantes utilisaient des threads en espace utilisateur ?
[^] # Re: une fôte
Posté par neologix . En réponse à la dépêche Le Top 500 de novembre 2009. Évalué à 7.
[^] # Re: Comme d'hab
Posté par neologix . En réponse au journal meme pas un mois.... Évalué à 9.